From sip-bounces@ietf.org Wed Mar 01 01:00:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEKLe-00031T-OS; Wed, 01 Mar 2006 00:58:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEKLc-00031O-CP for sip@ietf.org; Wed, 01 Mar 2006 00:58:04 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEKLa-0006Fk-LG for sip@ietf.org; Wed, 01 Mar 2006 00:58:04 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B3AE04F002D; Wed, 1 Mar 2006 06:57:59 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 06:57:59 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 06:57:59 +0100 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] Questions on subscription dialogs Date: Wed, 1 Mar 2006 06:57:58 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1ACC@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Questions on subscription dialogs Thread-Index: AcY8bRKliKrYTJ9dTEe2SyrXlveHrQAhWKdw From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 01 Mar 2006 05:57:59.0212 (UTC) FILETIME=[17E426C0:01C63CF5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Paul,=20 >>>If you have just a subscription, and what to change the target, you=20 >>>can use a resubscribe. No need to use UPDATE or INVITE to accomplish that. >>>=20 >>[CHH] I agree. However, my main issue was not so much related to=20 >>updating of the target, but more to the possibility to add media to an >>ongoing subscription dialog. >IMO the media is a property of an invite dialog usage. You can't add media directly to a dialog, you must first add an invite dialog usage to the dialog=20 >and then it can have media.=20 [CHH] Yes. The question is, again, whether you require a (re-)INVITE for that, or if you can use an UDPATE, but I guess that (and all other unwritten rules related to this) shall be defined (unless they already are) in the dialog usage draft. >I don't want to attempt drawing a UML diagram here with text art, so I will try to do it with text: [CHH] For the class dialog I guess you need two cseq attributes, one for each direction, as in chapter 1 of the dialog usage draft. And, one thing which is missing from your "UML diagram" is refer-dialogs. Because, I guess a refer dialog is not just a subscribe-dialog, is it? In fact, I think it would be good to document (e.g. in the dialog usage draft) also the different dialog usage "subclasses", and what information they contain. It may be obvious when reading the associated RFCs/drafts, but the dialog usage draft is supposed to collect this kind of information, so... Regards, Christer class: dialog attribute: cseq attribute: callid attribute: to-tag attribute: from-tag attribute: route set attribute: local contact attribute: remote contact attribute: ... subclass: zero or one invite-dialog-usage subclass: zero or more subscribe-dialog-usage class: invite-dialog-usage attribute: expiration-time attribute: active offer attribute: active answer attribute: offer/answer state attribute: pending offer attribute: pending answer attribute: zero or more media-session attribute: ... class: subscribe-dialog-usage attribute: expiration-time attribute: event-type attribute: event-parameters attribute: event-id attribute: direction (watcher/notifier) attribute: ... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 01 04:44:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FENrK-0001kI-Hl; Wed, 01 Mar 2006 04:43:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FENrJ-0001kD-4R for sip@ietf.org; Wed, 01 Mar 2006 04:43:01 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FENrI-0005z2-Cb for sip@ietf.org; Wed, 01 Mar 2006 04:43:01 -0500 Received: (qmail 10393 invoked by uid 0); 1 Mar 2006 09:42:55 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 1 Mar 2006 09:42:55 -0000 Message-ID: <002201c63d14$844bd3c0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" , "Christer Holmberg \(JO/LMF\)" References: <5EB80D22825EEE42872083AD5BFFB5945D1ABC@esealmw113.eemea.ericsson.se><440453A8.9020201@cisco.com> <44045C27.6000805@cisco.com> Subject: Re: [Sip] Questions on subscription dialogs (correction) Date: Wed, 1 Mar 2006 10:42:54 +0100 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.2670 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 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, What should also be mentioned here is RFC4235 (dialog event package) which is to my knowledge the first place where the dialog FSM is explicitly defined. Consequently, to support that package your 'dialog' class would need a 'state' attribute with values from { Trying, Early, Proceeding, Confirmed, Terminated } So attribute : state Furthermore, the dialog could also maintain state about the peer's SIP capabilities: attribute: allowedMethods attribute: allowedEvents attribute: acceptedContentTypes ( perhaps also for languages, encodings, etc, i.e. all the Accept-* headers) Then, for 100rel support you would need association: pending 100rel responses (i.e. those that have not been PRACKed yet) In addition, for dialog-usage (from RFC3261 section 12.1.1) attribute: secure I first considered this to be part of the dialog class, given that once the "secure" flag is set each Contact MUST be SIPS and hence a transition to unsecure is not possible. But then I realized that one could start unsecure (i.e. with INVITE sip:AoR ) but provide a SIPS Contact, then start a new dialog usage (e.g. SUBSCRIBE sips:Contact ) BTW, this leads me to think that this is an omission in RFC3261: It should state that 1) The "secure" flag should be set not only when the dialog-creating request is sent over TLS using a SIPS URI (section 12.1.2), but also when a SIPS Contact is provided 2) At the UAS side (section 12.1.1) the "secure" flag should be set not only when the request arrives over TLS, but also if the received Contact is SIPS or the Contact provided in the response is SIPS 3) The UAC should set its "secure" flag if the Contact provided in the dialog-creating response (by the UAS) is SIPS 4) The "secure" flag should be set when a target-refresh request includes a SIPS Contact Alternatively, perhaps it should explicitly be disallowed for UAC to send a request using "sip:" while providing a "sips:" Contact. A UAS that provides a "sips:" Contact for a "sip:" request is also questionable, since the other side may not support TLS. This is also something that could be stated explicitly Regards, jeroen >I botched up the data model I posted in the last message. (Too early in the >morning.) I will try again: > > class: dialog > attribute: cseq > attribute: callid > attribute: to-tag > attribute: from-tag > attribute: route set > attribute: local contact > attribute: remote contact > association: one or more dialog-usage > constraint: at most one invite-dialog-usage > attribute: ... > > class: dialog-usage > association: exactly one dialog > > class: invite-dialog-usage > superclass: dialog-usage > attribute: expiration-time > attribute: active offer > attribute: active answer > attribute: offer/answer state > attribute: pending offer > attribute: pending answer > attribute: zero or more media-session > attribute: ... > > class: subscribe-dialog-usage > superclass: dialog-usage > attribute: expiration-time > attribute: event-type > attribute: event-parameters > attribute: event-id > attribute: direction (watcher/notifier) > attribute: ... > > Paul Kyzivat wrote: >> Christer, >> >> More in line. Once again we are spelling out the unwritten rules of >> dialogs. >> >> Paul >> >> Christer Holmberg (JO/LMF) wrote: >> >>> Hi Paul, >>> >>> Thanks for your reply! Comments inline ([CHH]). >>> >>>>> Q1: Is it allowed to send non-NOTIFY request within a subscription >>>>> dialog (initiated by SUBSCRIBE), assuming the users support it? >>>>> >>>> >>>> Yes, with limits. In general, a request that is legal outside a dialog >>> >>> >>> is also legal within a dialog. (E.g. OPTIONS.) In some cases (e.g. >>> >>>> MESSAGE) other limitations have been applied. (You aren't supposed to >>> >>> >>> use MESSAGE within a dialog as a way to avoid session mode messaging.) >>> >>>> It is legal, though generally discouraged, to send requests within an >>> >>> >>> existing dialog that establish a new dialog usage. Sending an INVITE >>> within a >>> >>>> dialog established by a SUBSCRIBE falls into this category. >>> >>> >>> >>> [CHH] Is the discouragement documented somewhere? Or, is it just one of >>> the "unwritten rules"? :) >> >> >> I believe it has mostly been written in email threads here. I'm not sure >> if it is enshrined in any RFC or draft. (I think it might be mentioned in >> the target-dialog draft, and I think it might be mentioned in a draft by >> ben or robert.) >> >> I know there was a discussion thread a few months ago about this. I was >> nearly alone in advocating that shared dialogs are not always evil. >> >>>>> Q2: If Q1==TRUE, is it allowed to add media during a subscription >>>>> dialog, by sending an SDP offer in an UPDATE/re-INVITE? >>>> >>>> >>>> An INVITE in this case (at least the first one) would not be a >>> >>> >>> reINVITE. >>> >>>> It would establish a new invite dialog usage within an already >>> >>> >>> established dialog. >>> >>> [CHH] Well, it would contain a To tag, and I believe it is said >>> somewhere that it then should be treated as a re-INVITE. But, at the end >>> I guess it doesn't matter what we call it, as long as it is allowed to >>> send it. >> >> >> You may be right. The language in 3261 is very sloppy in this regard. It >> implies, but doesn't formalize, the notion of dialog usages, and mixes up >> dialogs and their usages a lot. IMO a reinvite refreshes an invite dialog >> usage. >> >>>> IMO an UPDATE is only permitted within an existing invite dialog usage. >>> >>> >>> >>>> So you would have to send an INVITE to establish the usage before you >>> >>> >>> could use UPDATE to do a subsequent offer/answer. >>> >>> [CHH] Where is that said? I was looking in RFC 3311, and eventhough the >>> text examples talk about INVITE initiated dialogs I didn't find any text >>> forbidding it to be used elswhere. But, of course I may have missed >>> it... >> >> >> I doubt it is said anywhere. Its another thing that has evolved via >> discussion, and enshrined in draft-sawada-sipping-sip-offeranswer-00. >> >>>>>> Q3: If Q2==TRUE, is it allowed to use re-INVITE, eventhough the >>> >>> >>> dialog was not initiated using INVITE? >>> >>>>> See above. Beware that I have heard of no implementation that actually >>> >>> >>> support this. >>> >>> [CHH] Neither have I - so far :) >>> >>> >>>>> Q4: If Q1==TRUE, if I send an empty re-INVITE within a subscription >>>>> dialog, e.g. to update the remote target, I assume the receiver MUST >>>>> create and include an SDP offer in the 200 OK response, eventhough no >>>>> media has previously been used within the dialog? >>>> >>>> >>>> Again see above. The invite must follow all the normal rules. >>>> >>>> Note that as defined, all the usages of the dialog share the same >>> >>> >>> targets. If you have a dialog shared by an invite usage and a subscribe >>> usage, then >>> >>>> either a reinvite or a resubscribe will update the target they share in >>> >>> >>> common. >>> >>> [CHH] I agree. It's still the same dialog, I think, eventhough there >>> seem to be different "usage" of it. But, if you use (re-)INVITE, an SDP >>> offer MUST be included (either in the request or response), according to >>> the normal rules. >> >> >> We are in violent agreement here. >> >>>> If you have just a subscription, and what to change the target, you can >>> >>> >>> use a resubscribe. No need to use UPDATE or INVITE to accomplish that. >>> >>> [CHH] I agree. However, my main issue was not so much related to >>> updating of the target, but more to the possibility to add media to an >>> ongoing subscription dialog. >> >> >> IMO the media is a property of an invite dialog usage. You can't add >> media directly to a dialog, you must first add an invite dialog usage to >> the dialog and then it can have media. I don't want to attempt drawing a >> UML diagram here with text art, so I will try to do it with text: >> >> class: dialog >> attribute: cseq >> attribute: callid >> attribute: to-tag >> attribute: from-tag >> attribute: route set >> attribute: local contact >> attribute: remote contact >> attribute: ... >> subclass: zero or one invite-dialog-usage >> subclass: zero or more subscribe-dialog-usage >> >> class: invite-dialog-usage >> attribute: expiration-time >> attribute: active offer >> attribute: active answer >> attribute: offer/answer state >> attribute: pending offer >> attribute: pending answer >> attribute: zero or more media-session >> attribute: ... >> >> class: subscribe-dialog-usage >> attribute: expiration-time >> attribute: event-type >> attribute: event-parameters >> attribute: event-id >> attribute: direction (watcher/notifier) >> attribute: ... >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 01 05:26:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEOVY-0002aA-51; Wed, 01 Mar 2006 05:24:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEOIc-0005Np-PW for sip@ietf.org; Wed, 01 Mar 2006 05:11:14 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEOIa-0006uU-S7 for sip@ietf.org; Wed, 01 Mar 2006 05:11:14 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 29118CAA; Wed, 1 Mar 2006 11:11:12 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 11:11:11 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 11:11:11 +0100 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] Questions on subscription dialogs Date: Wed, 1 Mar 2006 11:11:10 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1ADE@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Questions on subscription dialogs Thread-Index: AcY8eZOtBAjWaIe5T4W32SOtllfi5wAnsYKQ From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" , "Paul Kyzivat" X-OriginalArrivalTime: 01 Mar 2006 10:11:11.0248 (UTC) FILETIME=[770CE100:01C63D18] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 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 Jonathan, The draft does not currently cover the media issue. But, I think it SHALL cover it. Regards, Christer -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: 28. helmikuuta 2006 17:14 To: Paul Kyzivat Cc: Christer Holmberg (JO/LMF); IETF SIP List Subject: Re: [Sip] Questions on subscription dialogs I think most of the wisdom on dialog usages is captured in: http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-00.tx t -Jonathan R. Paul Kyzivat wrote: > Christer, >=20 > More in line. Once again we are spelling out the unwritten rules of=20 > dialogs. >=20 > Paul >=20 > Christer Holmberg (JO/LMF) wrote: >=20 >> Hi Paul, >> >> Thanks for your reply! Comments inline ([CHH]). >> >>>> Q1: Is it allowed to send non-NOTIFY request within a subscription=20 >>>> dialog (initiated by SUBSCRIBE), assuming the users support it? >>>> >>> >>> Yes, with limits. In general, a request that is legal outside a=20 >>> dialog >> >> >> is also legal within a dialog. (E.g. OPTIONS.) In some cases (e.g. >> >>> MESSAGE) other limitations have been applied. (You aren't supposed=20 >>> to >> >> >> use MESSAGE within a dialog as a way to avoid session mode=20 >> messaging.) >> >>> It is legal, though generally discouraged, to send requests within=20 >>> an >> >> >> existing dialog that establish a new dialog usage. Sending an INVITE=20 >> within a >> >>> dialog established by a SUBSCRIBE falls into this category. >> >> >> >> [CHH] Is the discouragement documented somewhere? Or, is it just one=20 >> of the "unwritten rules"? :) >=20 >=20 > I believe it has mostly been written in email threads here. I'm not=20 > sure if it is enshrined in any RFC or draft. (I think it might be=20 > mentioned in the target-dialog draft, and I think it might be=20 > mentioned in a draft by ben or robert.) >=20 > I know there was a discussion thread a few months ago about this. I=20 > was nearly alone in advocating that shared dialogs are not always evil. >=20 >>>> Q2: If Q1=3D=3DTRUE, is it allowed to add media during a = subscription=20 >>>> dialog, by sending an SDP offer in an UPDATE/re-INVITE? >>> >>> >>> An INVITE in this case (at least the first one) would not be a >> >> >> reINVITE. >> >>> It would establish a new invite dialog usage within an already >> >> >> established dialog. >> >> [CHH] Well, it would contain a To tag, and I believe it is said=20 >> somewhere that it then should be treated as a re-INVITE. But, at the=20 >> end I guess it doesn't matter what we call it, as long as it is=20 >> allowed to send it. >=20 >=20 > You may be right. The language in 3261 is very sloppy in this regard.=20 > It implies, but doesn't formalize, the notion of dialog usages, and=20 > mixes up dialogs and their usages a lot. IMO a reinvite refreshes an=20 > invite dialog usage. >=20 >>> IMO an UPDATE is only permitted within an existing invite dialog usage. >> >> >> >>> So you would have to send an INVITE to establish the usage before=20 >>> you >> >> >> could use UPDATE to do a subsequent offer/answer. >> >> [CHH] Where is that said? I was looking in RFC 3311, and eventhough=20 >> the text examples talk about INVITE initiated dialogs I didn't find=20 >> any text forbidding it to be used elswhere. But, of course I may have >> missed it... >=20 >=20 > I doubt it is said anywhere. Its another thing that has evolved via=20 > discussion, and enshrined in draft-sawada-sipping-sip-offeranswer-00. >=20 >>>>> Q3: If Q2=3D=3DTRUE, is it allowed to use re-INVITE, eventhough = the >> >> >> dialog was not initiated using INVITE? >> >>>> See above. Beware that I have heard of no implementation that=20 >>>> actually >> >> >> support this. >> >> [CHH] Neither have I - so far :) >> >> >>>> Q4: If Q1=3D=3DTRUE, if I send an empty re-INVITE within a = subscription >>>> dialog, e.g. to update the remote target, I assume the receiver=20 >>>> MUST create and include an SDP offer in the 200 OK response,=20 >>>> eventhough no media has previously been used within the dialog? >>> >>> >>> Again see above. The invite must follow all the normal rules. >>> >>> Note that as defined, all the usages of the dialog share the same >> >> >> targets. If you have a dialog shared by an invite usage and a=20 >> subscribe usage, then >> >>> either a reinvite or a resubscribe will update the target they share >>> in >> >> >> common. >> >> [CHH] I agree. It's still the same dialog, I think, eventhough there=20 >> seem to be different "usage" of it. But, if you use (re-)INVITE, an=20 >> SDP offer MUST be included (either in the request or response),=20 >> according to the normal rules. >=20 >=20 > We are in violent agreement here. >=20 >>> If you have just a subscription, and what to change the target, you=20 >>> can >> >> >> use a resubscribe. No need to use UPDATE or INVITE to accomplish that. >> >> [CHH] I agree. However, my main issue was not so much related to=20 >> updating of the target, but more to the possibility to add media to=20 >> an ongoing subscription dialog. >=20 >=20 > IMO the media is a property of an invite dialog usage. You can't add=20 > media directly to a dialog, you must first add an invite dialog usage=20 > to the dialog and then it can have media. I don't want to attempt=20 > drawing a UML diagram here with text art, so I will try to do it with text: >=20 > class: dialog > attribute: cseq > attribute: callid > attribute: to-tag > attribute: from-tag > attribute: route set > attribute: local contact > attribute: remote contact > attribute: ... > subclass: zero or one invite-dialog-usage > subclass: zero or more subscribe-dialog-usage >=20 > class: invite-dialog-usage > attribute: expiration-time > attribute: active offer > attribute: active answer > attribute: offer/answer state > attribute: pending offer > attribute: pending answer > attribute: zero or more media-session > attribute: ... >=20 > class: subscribe-dialog-usage > attribute: expiration-time > attribute: event-type > attribute: event-parameters > attribute: event-id > attribute: direction (watcher/notifier) > attribute: ... >=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 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 Mar 01 07:57:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQrX-0002Up-PQ; Wed, 01 Mar 2006 07:55:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQrV-0002OA-Kd for sip@ietf.org; Wed, 01 Mar 2006 07:55:25 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEQrT-0004le-A8 for sip@ietf.org; Wed, 01 Mar 2006 07:55:25 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 01 Mar 2006 04:55:24 -0800 X-IronPort-AV: i="4.02,156,1139212800"; d="scan'208"; a="1780845661:sNHT33446236" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k21CtLuj024825; Wed, 1 Mar 2006 04:55:22 -0800 (PST) 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.211); Wed, 1 Mar 2006 07:55:21 -0500 Received: from [10.86.240.63] ([10.86.240.63]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 07:55:21 -0500 Message-ID: <440599B9.4000307@cisco.com> Date: Wed, 01 Mar 2006 07:55:21 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Questions on subscription dialogs References: <5EB80D22825EEE42872083AD5BFFB5945D1ACC@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1ACC@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2006 12:55:21.0485 (UTC) FILETIME=[663FC3D0:01C63D2F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 Christer Holmberg (JO/LMF) wrote: > Hi Paul, > > >>>>If you have just a subscription, and what to change the target, you >>>>can use a resubscribe. No need to use UPDATE or INVITE to accomplish > > that. > >>>[CHH] I agree. However, my main issue was not so much related to >>>updating of the target, but more to the possibility to add media to an > > >>>ongoing subscription dialog. >> >>IMO the media is a property of an invite dialog usage. You can't add > > media directly to a dialog, you must first add an invite dialog usage to > the dialog > >>and then it can have media. > > > [CHH] Yes. The question is, again, whether you require a (re-)INVITE for > that, or if you can use an UDPATE, but I guess that (and all other > unwritten rules related to this) shall be defined (unless they already > are) in the dialog usage draft. IMO this stuff has been captured in the Sawada offer/answer draft. >>I don't want to attempt drawing a UML diagram here with text art, so I > > will try to do it with text: > > [CHH] For the class dialog I guess you need two cseq attributes, one for > each direction, as in chapter 1 of the dialog usage draft. Right. > And, one thing which is missing from your "UML diagram" is > refer-dialogs. Because, I guess a refer dialog is not just a > subscribe-dialog, is it? I've been through an implementation of this, and IMO a refer dialog usage is no different from a subscribe-dialog-usage. Different mechanisms are used to establish them, but once that process is kicked off there is no remaining difference - the same state is maintained for each, and the same mechanism (resubscribe) is used to refresh them. > In fact, I think it would be good to document (e.g. in the dialog usage > draft) also the different dialog usage "subclasses", and what > information they contain. It may be obvious when reading the associated > RFCs/drafts, but the dialog usage draft is supposed to collect this kind > of information, so... Yeah, that would be a good idea. Paul > Regards, > > Christer > > > class: dialog > attribute: cseq > attribute: callid > attribute: to-tag > attribute: from-tag > attribute: route set > attribute: local contact > attribute: remote contact > attribute: ... > subclass: zero or one invite-dialog-usage > subclass: zero or more subscribe-dialog-usage > > class: invite-dialog-usage > attribute: expiration-time > attribute: active offer > attribute: active answer > attribute: offer/answer state > attribute: pending offer > attribute: pending answer > attribute: zero or more media-session > attribute: ... > > class: subscribe-dialog-usage > attribute: expiration-time > attribute: event-type > attribute: event-parameters > attribute: event-id > attribute: direction (watcher/notifier) > attribute: ... > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 01 08:04:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQxv-0006T0-8t; Wed, 01 Mar 2006 08:02:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQxu-0006Sb-8j for sip@ietf.org; Wed, 01 Mar 2006 08:02:02 -0500 Received: from nproxy.gmail.com ([64.233.182.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEQxt-0004sy-04 for sip@ietf.org; Wed, 01 Mar 2006 08:02:02 -0500 Received: by nproxy.gmail.com with SMTP id c31so83575nfb for ; Wed, 01 Mar 2006 05:02:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=uN2WZgYreIwhVrAymcFUC48bD4f6PENlPph0iX+maJI38Qw9X+QldB64oz8eVfKE+GJLcwNTuMjesl9h63lVOabUOh+EQLzWRFBzGWPypMmsd8lagfcTN+44Xpn7Hxj6/kHpjTGFcjZ33peiiQuMsIPstJYYfDTb7Wfgk95oEYQ= Received: by 10.48.213.18 with SMTP id l18mr73960nfg; Wed, 01 Mar 2006 05:01:59 -0800 (PST) Received: by 10.49.35.18 with HTTP; Wed, 1 Mar 2006 05:01:59 -0800 (PST) Message-ID: <52db68bc0603010501p5c8d5a99jee98901258da0c8e@mail.gmail.com> Date: Wed, 1 Mar 2006 18:31:59 +0530 From: "Sudhir Kumar Reddy" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Sip] query about IMS X-BeenThere: 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="===============1349090947==" Errors-To: sip-bounces@ietf.org --===============1349090947== Content-Type: multipart/alternative; boundary="----=_Part_15715_15320375.1141218119674" ------=_Part_15715_15320375.1141218119674 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All, I would like to know is there any forum or mailing list for IMS. thanks in advance best regards Sudhir ------=_Part_15715_15320375.1141218119674 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi All,
 
I would like to know is there any forum or mailing list for IMS.
 
thanks in advance
 
best regards
Sudhir
 
 
------=_Part_15715_15320375.1141218119674-- --===============1349090947== 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 --===============1349090947==-- From sip-bounces@ietf.org Wed Mar 01 08:14:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FER7h-0005pB-VV; Wed, 01 Mar 2006 08:12:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FER7h-0005on-BP for sip@ietf.org; Wed, 01 Mar 2006 08:12:09 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FER7f-0005C5-Tz for sip@ietf.org; Wed, 01 Mar 2006 08:12:09 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0C73E4F0002; Wed, 1 Mar 2006 14:12:07 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 14:12:06 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 14:12:06 +0100 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] Questions on subscription dialogs Date: Wed, 1 Mar 2006 14:12:05 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1AE2@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Questions on subscription dialogs Thread-Index: AcY9L2ocA/rnOxuDQ9Ktw2+IcT2k6AAATLxw From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 01 Mar 2006 13:12:06.0466 (UTC) FILETIME=[BD43B220:01C63D31] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 >>[CHH] Yes. The question is, again, whether you require a (re-)INVITE=20 >>for that, or if you can use an UDPATE, but I guess that (and all other >>unwritten rules related to this) shall be defined (unless they already >>are) in the dialog usage draft. >IMO this stuff has been captured in the Sawada offer/answer draft. [CHH] Fair enough, I'll check that. However, the usage of UPDATE as such within a non-invite dialog has nothing to do with offer/answer, and should also be documented in a dialog related specification. >>And, one thing which is missing from your "UML diagram" is=20 >>refer-dialogs. Because, I guess a refer dialog is not just a=20 >>subscribe-dialog, is it? >I've been through an implementation of this, and IMO a refer dialog usage is no different from a subscribe-dialog-usage. Different mechanisms are used to=20 >establish them, but once that process is kicked off there is no remaining difference - the same state is maintained for each, and the same mechanism=20 >(resubscribe) is used to refresh them. [CHH] The REFER request does not contain subscription duration information. So, if there are no resubscribes, for how long does the refer dialog live? And, if I send the REFER request within a invite dialog, and then send BYE for the invite dialog, the refer dialog will stay alive? 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 Mar 01 08:23:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERGl-00086T-Nx; Wed, 01 Mar 2006 08:21:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERGk-00086O-FY for sip@ietf.org; Wed, 01 Mar 2006 08:21:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FERGj-0005RV-Q7 for sip@ietf.org; Wed, 01 Mar 2006 08:21:30 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 01 Mar 2006 05:21:29 -0800 X-IronPort-AV: i="4.02,156,1139212800"; d="scan'208"; a="1780851999:sNHT37628228" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k21DLRul003826; Wed, 1 Mar 2006 05:21:29 -0800 (PST) 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.211); Wed, 1 Mar 2006 08:21:28 -0500 Received: from [10.86.240.63] ([10.86.240.63]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 08:21:27 -0500 Message-ID: <44059FD7.7000005@cisco.com> Date: Wed, 01 Mar 2006 08:21:27 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Questions on subscription dialogs (correction) References: <5EB80D22825EEE42872083AD5BFFB5945D1ABC@esealmw113.eemea.ericsson.se><440453A8.9020201@cisco.com> <44045C27.6000805@cisco.com> <002201c63d14$844bd3c0$31713b51@BEMBUSTER> In-Reply-To: <002201c63d14$844bd3c0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2006 13:21:27.0930 (UTC) FILETIME=[0BEC4DA0:01C63D33] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: IETF SIP List , "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 sense some interest in doing some work here. Given all the discussion about the amount of work in the groups, we should discuss whether this is work the group (presumably sip or sipping) wants to take on. Maybe this is a subject for hallway discussion at the Dallas meeting. More inline. Paul Jeroen van Bemmel wrote: > Paul, > > What should also be mentioned here is RFC4235 (dialog event package) > which is to my knowledge the first place where the dialog FSM is > explicitly defined. Consequently, to support that package your 'dialog' > class would need a 'state' attribute with values from { Trying, Early, > Proceeding, Confirmed, Terminated } > > So > attribute : state In spite of its name, the dialog event package isn't about dialogs, it is about invite dialog usages. (It doesn't report anything about subscriptions.) So that attribute needs to be added to invite dialog usage. > Furthermore, the dialog could also maintain state about the peer's SIP > capabilities: > attribute: allowedMethods > attribute: allowedEvents > attribute: acceptedContentTypes ( perhaps also for languages, encodings, > etc, i.e. all the Accept-* headers) This is a hot button of mine. The scope is currently undefined for Supported, Required, Accept-*. It is debatable whether they are or should be dialog scoped. > Then, for 100rel support you would need > association: pending 100rel responses (i.e. those that have not been > PRACKed yet) Yup. > In addition, for dialog-usage (from RFC3261 section 12.1.1) > attribute: secure > I first considered this to be part of the dialog class, given that once > the "secure" flag is set each Contact MUST be SIPS and hence a > transition to unsecure is not possible. But then I realized that one > could start unsecure (i.e. with INVITE sip:AoR ) but provide a SIPS > Contact, then start a new dialog usage (e.g. SUBSCRIBE sips:Contact ) I'm not at all sure about this. (Haven't thought about it.) But target refresh affects all usages, so if target refresh affects the secure flag, then that would be dialog state. > BTW, this leads me to think that this is an omission in RFC3261: It > should state that > 1) The "secure" flag should be set not only when the dialog-creating > request is sent over TLS using a SIPS URI (section 12.1.2), but also > when a SIPS Contact is provided > 2) At the UAS side (section 12.1.1) the "secure" flag should be set not > only when the request arrives over TLS, but also if the received Contact > is SIPS or the Contact provided in the response is SIPS > 3) The UAC should set its "secure" flag if the Contact provided in the > dialog-creating response (by the UAS) is SIPS > 4) The "secure" flag should be set when a target-refresh request > includes a SIPS Contact > > Alternatively, perhaps it should explicitly be disallowed for UAC to > send a request using "sip:" while providing a "sips:" Contact. A UAS > that provides a "sips:" Contact for a "sip:" request is also > questionable, since the other side may not support TLS. This is also > something that could be stated explicitly > > Regards, > > jeroen > >> I botched up the data model I posted in the last message. (Too early >> in the morning.) I will try again: >> >> class: dialog >> attribute: cseq >> attribute: callid >> attribute: to-tag >> attribute: from-tag >> attribute: route set >> attribute: local contact >> attribute: remote contact >> association: one or more dialog-usage >> constraint: at most one invite-dialog-usage >> attribute: ... >> >> class: dialog-usage >> association: exactly one dialog >> >> class: invite-dialog-usage >> superclass: dialog-usage >> attribute: expiration-time >> attribute: active offer >> attribute: active answer >> attribute: offer/answer state >> attribute: pending offer >> attribute: pending answer >> attribute: zero or more media-session >> attribute: ... >> >> class: subscribe-dialog-usage >> superclass: dialog-usage >> attribute: expiration-time >> attribute: event-type >> attribute: event-parameters >> attribute: event-id >> attribute: direction (watcher/notifier) >> attribute: ... >> >> Paul Kyzivat wrote: >> >>> Christer, >>> >>> More in line. Once again we are spelling out the unwritten rules of >>> dialogs. >>> >>> Paul >>> >>> Christer Holmberg (JO/LMF) wrote: >>> >>>> Hi Paul, >>>> >>>> Thanks for your reply! Comments inline ([CHH]). >>>> >>>>>> Q1: Is it allowed to send non-NOTIFY request within a subscription >>>>>> dialog (initiated by SUBSCRIBE), assuming the users support it? >>>>>> >>>>> >>>>> Yes, with limits. In general, a request that is legal outside a dialog >>>> >>>> >>>> >>>> is also legal within a dialog. (E.g. OPTIONS.) In some cases (e.g. >>>> >>>>> MESSAGE) other limitations have been applied. (You aren't supposed to >>>> >>>> >>>> >>>> use MESSAGE within a dialog as a way to avoid session mode messaging.) >>>> >>>>> It is legal, though generally discouraged, to send requests within an >>>> >>>> >>>> >>>> existing dialog that establish a new dialog usage. Sending an INVITE >>>> within a >>>> >>>>> dialog established by a SUBSCRIBE falls into this category. >>>> >>>> >>>> >>>> >>>> [CHH] Is the discouragement documented somewhere? Or, is it just one of >>>> the "unwritten rules"? :) >>> >>> >>> >>> I believe it has mostly been written in email threads here. I'm not >>> sure if it is enshrined in any RFC or draft. (I think it might be >>> mentioned in the target-dialog draft, and I think it might be >>> mentioned in a draft by ben or robert.) >>> >>> I know there was a discussion thread a few months ago about this. I >>> was nearly alone in advocating that shared dialogs are not always evil. >>> >>>>>> Q2: If Q1==TRUE, is it allowed to add media during a subscription >>>>>> dialog, by sending an SDP offer in an UPDATE/re-INVITE? >>>>> >>>>> >>>>> >>>>> An INVITE in this case (at least the first one) would not be a >>>> >>>> >>>> >>>> reINVITE. >>>> >>>>> It would establish a new invite dialog usage within an already >>>> >>>> >>>> >>>> established dialog. >>>> >>>> [CHH] Well, it would contain a To tag, and I believe it is said >>>> somewhere that it then should be treated as a re-INVITE. But, at the >>>> end >>>> I guess it doesn't matter what we call it, as long as it is allowed to >>>> send it. >>> >>> >>> >>> You may be right. The language in 3261 is very sloppy in this regard. >>> It implies, but doesn't formalize, the notion of dialog usages, and >>> mixes up dialogs and their usages a lot. IMO a reinvite refreshes an >>> invite dialog usage. >>> >>>>> IMO an UPDATE is only permitted within an existing invite dialog >>>>> usage. >>>> >>>> >>>> >>>> >>>>> So you would have to send an INVITE to establish the usage before you >>>> >>>> >>>> >>>> could use UPDATE to do a subsequent offer/answer. >>>> >>>> [CHH] Where is that said? I was looking in RFC 3311, and eventhough the >>>> text examples talk about INVITE initiated dialogs I didn't find any >>>> text >>>> forbidding it to be used elswhere. But, of course I may have missed >>>> it... >>> >>> >>> >>> I doubt it is said anywhere. Its another thing that has evolved via >>> discussion, and enshrined in draft-sawada-sipping-sip-offeranswer-00. >>> >>>>>>> Q3: If Q2==TRUE, is it allowed to use re-INVITE, eventhough the >>>> >>>> >>>> >>>> dialog was not initiated using INVITE? >>>> >>>>>> See above. Beware that I have heard of no implementation that >>>>>> actually >>>> >>>> >>>> >>>> support this. >>>> >>>> [CHH] Neither have I - so far :) >>>> >>>> >>>>>> Q4: If Q1==TRUE, if I send an empty re-INVITE within a >>>>>> subscription dialog, e.g. to update the remote target, I assume >>>>>> the receiver MUST create and include an SDP offer in the 200 OK >>>>>> response, eventhough no media has previously been used within the >>>>>> dialog? >>>>> >>>>> >>>>> >>>>> Again see above. The invite must follow all the normal rules. >>>>> >>>>> Note that as defined, all the usages of the dialog share the same >>>> >>>> >>>> >>>> targets. If you have a dialog shared by an invite usage and a subscribe >>>> usage, then >>>> >>>>> either a reinvite or a resubscribe will update the target they >>>>> share in >>>> >>>> >>>> >>>> common. >>>> >>>> [CHH] I agree. It's still the same dialog, I think, eventhough there >>>> seem to be different "usage" of it. But, if you use (re-)INVITE, an SDP >>>> offer MUST be included (either in the request or response), >>>> according to >>>> the normal rules. >>> >>> >>> >>> We are in violent agreement here. >>> >>>>> If you have just a subscription, and what to change the target, you >>>>> can >>>> >>>> >>>> >>>> use a resubscribe. No need to use UPDATE or INVITE to accomplish that. >>>> >>>> [CHH] I agree. However, my main issue was not so much related to >>>> updating of the target, but more to the possibility to add media to an >>>> ongoing subscription dialog. >>> >>> >>> >>> IMO the media is a property of an invite dialog usage. You can't add >>> media directly to a dialog, you must first add an invite dialog usage >>> to the dialog and then it can have media. I don't want to attempt >>> drawing a UML diagram here with text art, so I will try to do it with >>> text: >>> >>> class: dialog >>> attribute: cseq >>> attribute: callid >>> attribute: to-tag >>> attribute: from-tag >>> attribute: route set >>> attribute: local contact >>> attribute: remote contact >>> attribute: ... >>> subclass: zero or one invite-dialog-usage >>> subclass: zero or more subscribe-dialog-usage >>> >>> class: invite-dialog-usage >>> attribute: expiration-time >>> attribute: active offer >>> attribute: active answer >>> attribute: offer/answer state >>> attribute: pending offer >>> attribute: pending answer >>> attribute: zero or more media-session >>> attribute: ... >>> >>> class: subscribe-dialog-usage >>> attribute: expiration-time >>> attribute: event-type >>> attribute: event-parameters >>> attribute: event-id >>> attribute: direction (watcher/notifier) >>> attribute: ... >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 01 08:33:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERQ7-0002WU-Cq; Wed, 01 Mar 2006 08:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERQ4-0002W9-LS for sip@ietf.org; Wed, 01 Mar 2006 08:31:08 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FERQ1-0005gr-CJ for sip@ietf.org; Wed, 01 Mar 2006 08:31:08 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 01 Mar 2006 05:31:04 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,156,1139212800"; d="scan'208"; a="22788482:sNHT23527172" 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 k21DV3qM017714; Wed, 1 Mar 2006 08:31:03 -0500 (EST) 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.211); Wed, 1 Mar 2006 08:31:03 -0500 Received: from [10.86.240.63] ([10.86.240.63]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 08:31:03 -0500 Message-ID: <4405A216.4020508@cisco.com> Date: Wed, 01 Mar 2006 08:31:02 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Questions on subscription dialogs References: <5EB80D22825EEE42872083AD5BFFB5945D1AE2@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1AE2@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2006 13:31:03.0356 (UTC) FILETIME=[62E757C0:01C63D34] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Christer Holmberg (JO/LMF) wrote: > Hi, > > >>>[CHH] Yes. The question is, again, whether you require a (re-)INVITE >>>for that, or if you can use an UDPATE, but I guess that (and all other > > >>>unwritten rules related to this) shall be defined (unless they already >>>are) in the dialog usage draft. >> >>IMO this stuff has been captured in the Sawada offer/answer draft. > > > [CHH] Fair enough, I'll check that. > > However, the usage of UPDATE as such within a non-invite dialog has > nothing to do with offer/answer, and should also be documented in a > dialog related specification. Perhaps. IMO it should simply state that such usage is not permitted. >>>And, one thing which is missing from your "UML diagram" is >>>refer-dialogs. Because, I guess a refer dialog is not just a >>>subscribe-dialog, is it? >> >>I've been through an implementation of this, and IMO a refer dialog > > usage is no different from a subscribe-dialog-usage. Different > mechanisms are used to > >>establish them, but once that process is kicked off there is no > > remaining difference - the same state is maintained for each, and the > same mechanism > >>(resubscribe) is used to refresh them. > > > [CHH] The REFER request does not contain subscription duration > information. So, if there are no resubscribes, for how long does the > refer dialog live? I think that is covered in the REFER RFC. How the value is initially determined is part of the unique process of establishing the usage, but once established IMO it is no different. In other words, *some* expiration time is determined and becomes part of the state. > And, if I send the REFER request within a invite dialog, and then send > BYE for the invite dialog, the refer dialog will stay alive? IMO it is clear that the refer dialog usage MUST stay alive until the watcher terminates it with resubscribe or the notifier terminates it with a final NOTIFY. Like most of this information, I think this is implied by current RFCs but is often not very explicitly called out. So explicit clarification is desirable. Paul 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 Wed Mar 01 08:48:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERfD-0005cy-Sy; Wed, 01 Mar 2006 08:46:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERfC-0005co-BX for sip@ietf.org; Wed, 01 Mar 2006 08:46:46 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FERfB-0006DK-Ke for sip@ietf.org; Wed, 01 Mar 2006 08:46:46 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F06824F0027; Wed, 1 Mar 2006 14:46:44 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 14:46:44 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 14:46:44 +0100 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] Questions on subscription dialogs Date: Wed, 1 Mar 2006 14:46:43 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1AE4@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Questions on subscription dialogs Thread-Index: AcY9NG44b9aLWrz5Tby6+H6yK79tuAAAFkYw From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 01 Mar 2006 13:46:44.0334 (UTC) FILETIME=[93C530E0:01C63D36] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 >>[CHH] Fair enough, I'll check that. >>=20 >>However, the usage of UPDATE as such within a non-invite dialog has=20 >>nothing to do with offer/answer, and should also be documented in a=20 >>dialog related specification. >Perhaps. IMO it should simply state that such usage is not permitted. [CHH] IF that is the decission, yes, assuming that SUBSCRIBE (for subscription dialogs) can be used to achieve everything legal one would like to use UPDATE for. I am not arguing against you - I just think we need to be very sure.=20 >>[CHH] The REFER request does not contain subscription duration=20 >>information. So, if there are no resubscribes, for how long does the=20 >>refer dialog live? >I think that is covered in the REFER RFC. How the value is initially determined is part of the unique process of establishing the usage, but once=20 >established IMO it is no different. In other words, *some* expiration time is determined and becomes part of the state. >>And, if I send the REFER request within a invite dialog, and then send >>BYE for the invite dialog, the refer dialog will stay alive? >IMO it is clear that the refer dialog usage MUST stay alive until the watcher terminates it with resubscribe or the notifier terminates it with a final=20 >NOTIFY. What if there never is any NOTIFY, and no resubscribe? I know this would happen mostly/only in error cases, e.g. when end-points are rebooted etc, but it may happen. Yes, one CAN say it's an "implementation issue". For invite dialogs this can be handled using the session-timer mechanism, but it can't be used for a refer/subscription dialog... The session-timer, and how it affects different dialog usages, is probably something that should also be mentioned in the dialog usage draft, I think. >Like most of this information, I think this is implied by current RFCs but is often not very explicitly called out. So explicit clarification is=20 >desirable. The problem is that the old RFCs don't (for obvious reasons) talk about dialog usage. They talk more about "requests within existing dialogs", and then it's not that obvious that terminating that existing dialog may not necessarily terminate whatever the request created. 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 Mar 01 10:02:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESoL-0006E8-Td; Wed, 01 Mar 2006 10:00:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESoA-0005m6-Sq for sip@ietf.org; Wed, 01 Mar 2006 10:00:06 -0500 Received: from empbedex2.empirix.com ([12.38.203.92] helo=EMPBEDEX.empirix.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESo7-0000at-KW for sip@ietf.org; Wed, 01 Mar 2006 10:00:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] query about IMS Date: Wed, 1 Mar 2006 10:00:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] query about IMS Thread-Index: AcY9MGLvi8fNBNSXSBOiDZB0Zi5l/AAEEGow From: "Beith, Gordon" To: "Sudhir Kumar Reddy" , X-Spam-Score: 0.2 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f 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="===============0081354697==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0081354697== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63D40.D051AE79" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63D40.D051AE79 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a new Forum, called IMS Forum. http://www.imsforum.org/ =20 =20 ________________________________ From: Sudhir Kumar Reddy [mailto:t.sudhirkumar@gmail.com]=20 Sent: Wednesday, March 01, 2006 8:02 AM To: sip@ietf.org Subject: [Sip] query about IMS =20 Hi All, =20 I would like to know is there any forum or mailing list for IMS. =20 thanks in advance =20 best regards Sudhir =20 =20 ------_=_NextPart_001_01C63D40.D051AE79 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is a new Forum, called IMS = Forum. http://www.imsforum.org/=

 

 

From: = Sudhir Kumar Reddy [mailto:t.sudhirkumar@gmail.com]
Sent: Wednesday, March = 01, 2006 8:02 AM
To: sip@ietf.org
Subject: [Sip] query = about IMS

 

Hi All,

 

I would like to know is there any forum or mailing list for = IMS.

 

thanks in advance

 

best regards

Sudhir

 

 

------_=_NextPart_001_01C63D40.D051AE79-- --===============0081354697== 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 --===============0081354697==-- From sip-bounces@ietf.org Wed Mar 01 10:12:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESyO-0004ZB-K9; Wed, 01 Mar 2006 10:10:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESyN-0004YY-Ls for sip@ietf.org; Wed, 01 Mar 2006 10:10:39 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESyK-000138-62 for sip@ietf.org; Wed, 01 Mar 2006 10:10:39 -0500 Received: from [10.147.65.87] (gorn [10.147.65.87]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k21FAZv25615 for ; Wed, 1 Mar 2006 16:10:35 +0100 (MET) Message-ID: <4405B96A.4080107@fokus.fraunhofer.de> Date: Wed, 01 Mar 2006 16:10:34 +0100 From: Sven Ehlert Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------060809010808060902000809" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [Sip] CFP: Third VoIP Security Workshop, Deadline extended X-BeenThere: sip@ietf.org X-Mailman-Version: 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. --------------060809010808060902000809 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.fraunhofer.de id k21FAZv25615 Third Annual VoIP Security Workshop In Cooperation with ACM SIGCOMM Berlin, Germany 01, 02 June 2006 www.iptel.org/voipsecurity Submission Deadline: 15.03.06 This security workshop is the third following successful events in Dallas 2004 and Washington 2005. The workshop addresses the challenges, advanced technologies and regulations for providing secure VoIP services in the Internet as well as in third generation networks. The 2006 workshop will extend the scope of VoIP security to IMS services and present the latest advances in denial of service and SPIT detection and protection mechanisms. The format of the workshop is based on two-day single-track sessions, with presentations of invited and regular papers from academia and industry. The papers solicited in the Third VoIP Security workshop cover a variety of topics including but not limited to: * Intrusion and anomaly detection of VoIP and IMS systems * SPIT/SPIM detection and prevention * Threat and vulnerability analyses of VoIP and IMS systems * Regulatory aspects of VoIP and IMS communication * Securing Peer-to-peer systems * Securing service creation environments * Privacy and anonymity * Monitoring and testing tools for VoIP and IMS infrastructures * Security of VoIP supporting systems such as AAA and ENUM * Support of lawful interception and securing emergency services in VoIP and IMS services * High availability solutions for VoIP and IMS systems The Third VoIP Security workshop is a two day workshop with a special session of invited papers from industry and government. The program committee will referee all papers, and accepted papers will be published in the conference proceedings Important Dates: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Full paper submission deadline: March 15, 2006 * Notification of acceptance: April 10, 2006 * Camera ready submission: May 01, 2006 General Chair: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Radu Popescu-Zeletin Fraunhofer Fokus Program Chairs: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dorgham Sisalem Tekelec Ram Dantu University of North Texas Henning Schulzrinne Columbia University Local Organization Chair: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sven Ehlert Fraunhofer Fokus Technical Program Committee =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ralf Ackermann TU Darmstadt Hossam Afifi INT Evry Elisa Bertino Purdue University George Carle T=FCbingen University Jasson Casey Alcatel Ram Dantu University of North Texas Sven Ehlert Fraunhofer Fokus Sonia Fahmy Purdue University Dipak Ghosal University of California Davis G=FCnter M=FCller University of Freiburg Saverio Niccolini NEC Labs Europe J=F6rg Ott Helsinki University of Technolo= gy Ozgur Gurleyen Vodafone Basavaraj Patil Nokia Neeli Rashmi Prasad University of Aalborg Pradeep Samudra Samsung Peter Schoo DoCoMo Euro-Labs Henning Schulzrinne Columbia University Dorgham Sisalem Tekelec Jeff Smith DHS Burkhard Stiller University of Zurich and ETH Zuri= ch Duminda Wijesekeara George Mason University --------------060809010808060902000809 Content-Type: text/x-vcard; charset=utf-8; name="ehlert.vcf" Content-Disposition: attachment; filename="ehlert.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Sven Ehlert n:Ehlert;Sven org:NGNI;Fraunhofer FOKUS adr:;;Kaiserin-Augusta-Allee 31;Berlin;;10589;Germany email;internet:ehlert@fokus.fraunhofer.de tel;work:+49-30-3463-7378 tel;fax:+49-30-3463-8000 note:sip:ehlert@iptel.org url:http://www.fokus.fraunhofer.de version:2.1 end:vcard --------------060809010808060902000809 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 --------------060809010808060902000809-- From sip-bounces@ietf.org Wed Mar 01 11:04:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETmX-0004Nb-Bv; Wed, 01 Mar 2006 11:02:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETmV-0004MN-8Q for sip@ietf.org; Wed, 01 Mar 2006 11:02:27 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FETmT-0003oI-UB for sip@ietf.org; Wed, 01 Mar 2006 11:02:27 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 01 Mar 2006 08:02:25 -0800 X-IronPort-AV: i="4.02,157,1139212800"; d="scan'208,217"; a="1780911994:sNHT3991643000" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k21G2NXf013564; Wed, 1 Mar 2006 08:02:23 -0800 (PST) Received: from 10.21.122.48 ([10.21.122.48]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Mar 2006 16:02:23 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 01 Mar 2006 08:02:21 -0800 Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing and Conquering From: Cullen Jennings To: "sip@ietf.org" Message-ID: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing and Conquering Thread-Index: AcY9SYWZxE7dKqk8EdqQ/AARJEEJ/A== In-Reply-To: Mime-version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Avshalom Houri X-BeenThere: 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="===============1820331104==" Errors-To: sip-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1820331104== Content-type: multipart/alternative; boundary="B_3224044942_362119" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3224044942_362119 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Please move this thread to sipping list only for now. On 2/28/06 5:51 AM, "Avshalom Houri" wrote: > > Just a small optimization suggestion, can we decide to continue this > discussion either in sip or sipping (sipping probably is more appropriate for > this). > We do not need to get a multiple copy of the message so near to the next IETF > when the IETF mailing lists are full anyway (people that are in the to or > cc list get 3 copies...) > > Thanks > --Avshalom > > > _______________________________________________ > 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 --B_3224044942_362119 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing and Co= nquering
Please move this thread to sipping list only for now.


On 2/28/06 5:51 AM, "Avshalom Houri" <AVSHALOM@il.ibm.com> = wrote:


Just a small optimization suggestion, can we decide to continue this discus= sion either in sip or sipping (sipping probably is more appropriate for this= ).
We do not need to get a multiple copy of the message so near to the next IE= TF when the IETF mailing lists are full anyway (people that are in the to or=
cc list get 3 copies...)

Thanks
--Avshalom

____________________= ___________________________
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

 --B_3224044942_362119-- --===============1820331104== 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 --===============1820331104==-- From sip-bounces@ietf.org Wed Mar 01 11:06:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEToW-0006CV-VH; Wed, 01 Mar 2006 11:04:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEToV-0006CQ-Ua for sip@ietf.org; Wed, 01 Mar 2006 11:04:31 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEToT-0003tm-Jh for sip@ietf.org; Wed, 01 Mar 2006 11:04:31 -0500 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k21G4htY032687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Mar 2006 10:04:43 -0600 Message-ID: <4405C60B.9020006@softarmor.com> Date: Wed, 01 Mar 2006 10:04:27 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sudhir Kumar Reddy Subject: Re: [Sip] query about IMS References: <52db68bc0603010501p5c8d5a99jee98901258da0c8e@mail.gmail.com> In-Reply-To: <52db68bc0603010501p5c8d5a99jee98901258da0c8e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Sudhir Kumar Reddy wrote: > Hi All, > > I would like to know is there any forum or mailing list for IMS. > IMS is mostly defined in 3GPP, and 3GPP2 applies it to CDMA networks. Both have big web sites with large collections of documents and dozens of mailing lists. Active participation in each requires some level of membership, but their published specifications are avalable for download. http://www.3gpp.org http://www.3gpp2.org -- 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 Mar 01 11:16:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETxs-0004QQ-7M; Wed, 01 Mar 2006 11:14:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETxq-0004NW-1r for sip@ietf.org; Wed, 01 Mar 2006 11:14:10 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FETxo-0004HR-IE for sip@ietf.org; Wed, 01 Mar 2006 11:14:10 -0500 Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k21GDtd2014356 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 1 Mar 2006 10:13:55 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1ADE@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1ADE@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <546B381B-E049-4685-AF56-0B4CA329B760@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Questions on subscription dialogs Date: Wed, 1 Mar 2006 10:13:54 -0600 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (shaman.nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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 Christer - I'm not yet sure exactly what you're looking for the draft to cover wrt the media issue. Was it specifically an answer to your first question? If not, could you summarize for me? The draft talks about dialogs and dialog usages in general. It uses SUBSCRIBE dialogs only as motivating examples. To respond to your initial question - as this draft points out, you are asking for a world of interoperability hurt to attempt to create an INVITE usage inside the SUBSCRIBE usage. Yes - it is legal per 3261, but the general consensus is that it is a really bad idea, and the intent of the dialog-usage draft is to capture why. RjS On Mar 1, 2006, at 4:11 AM, Christer Holmberg ((JO/LMF)) wrote: > > Hi Jonathan, > > The draft does not currently cover the media issue. But, I think it > SHALL cover it. > > Regards, > > Christer > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 28. helmikuuta 2006 17:14 > To: Paul Kyzivat > Cc: Christer Holmberg (JO/LMF); IETF SIP List > Subject: Re: [Sip] Questions on subscription dialogs > > I think most of the wisdom on dialog usages is captured in: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping- > dialogusage-00.tx > t > > -Jonathan R. > > Paul Kyzivat wrote: > >> Christer, >> >> More in line. Once again we are spelling out the unwritten rules of >> dialogs. >> >> Paul >> >> Christer Holmberg (JO/LMF) wrote: >> >>> Hi Paul, >>> >>> Thanks for your reply! Comments inline ([CHH]). >>> >>>>> Q1: Is it allowed to send non-NOTIFY request within a subscription >>>>> dialog (initiated by SUBSCRIBE), assuming the users support it? >>>>> >>>> >>>> Yes, with limits. In general, a request that is legal outside a >>>> dialog >>> >>> >>> is also legal within a dialog. (E.g. OPTIONS.) In some cases (e.g. >>> >>>> MESSAGE) other limitations have been applied. (You aren't supposed >>>> to >>> >>> >>> use MESSAGE within a dialog as a way to avoid session mode >>> messaging.) >>> >>>> It is legal, though generally discouraged, to send requests within >>>> an >>> >>> >>> existing dialog that establish a new dialog usage. Sending an INVITE >>> within a >>> >>>> dialog established by a SUBSCRIBE falls into this category. >>> >>> >>> >>> [CHH] Is the discouragement documented somewhere? Or, is it just one >>> of the "unwritten rules"? :) >> >> >> I believe it has mostly been written in email threads here. I'm not >> sure if it is enshrined in any RFC or draft. (I think it might be >> mentioned in the target-dialog draft, and I think it might be >> mentioned in a draft by ben or robert.) >> >> I know there was a discussion thread a few months ago about this. I >> was nearly alone in advocating that shared dialogs are not always > evil. >> >>>>> Q2: If Q1==TRUE, is it allowed to add media during a subscription >>>>> dialog, by sending an SDP offer in an UPDATE/re-INVITE? >>>> >>>> >>>> An INVITE in this case (at least the first one) would not be a >>> >>> >>> reINVITE. >>> >>>> It would establish a new invite dialog usage within an already >>> >>> >>> established dialog. >>> >>> [CHH] Well, it would contain a To tag, and I believe it is said >>> somewhere that it then should be treated as a re-INVITE. But, at the >>> end I guess it doesn't matter what we call it, as long as it is >>> allowed to send it. >> >> >> You may be right. The language in 3261 is very sloppy in this regard. >> It implies, but doesn't formalize, the notion of dialog usages, and >> mixes up dialogs and their usages a lot. IMO a reinvite refreshes an >> invite dialog usage. >> >>>> IMO an UPDATE is only permitted within an existing invite dialog > usage. >>> >>> >>> >>>> So you would have to send an INVITE to establish the usage before >>>> you >>> >>> >>> could use UPDATE to do a subsequent offer/answer. >>> >>> [CHH] Where is that said? I was looking in RFC 3311, and eventhough >>> the text examples talk about INVITE initiated dialogs I didn't find >>> any text forbidding it to be used elswhere. But, of course I may >>> have > >>> missed it... >> >> >> I doubt it is said anywhere. Its another thing that has evolved via >> discussion, and enshrined in draft-sawada-sipping-sip-offeranswer-00. >> >>>>>> Q3: If Q2==TRUE, is it allowed to use re-INVITE, eventhough the >>> >>> >>> dialog was not initiated using INVITE? >>> >>>>> See above. Beware that I have heard of no implementation that >>>>> actually >>> >>> >>> support this. >>> >>> [CHH] Neither have I - so far :) >>> >>> >>>>> Q4: If Q1==TRUE, if I send an empty re-INVITE within a >>>>> subscription > >>>>> dialog, e.g. to update the remote target, I assume the receiver >>>>> MUST create and include an SDP offer in the 200 OK response, >>>>> eventhough no media has previously been used within the dialog? >>>> >>>> >>>> Again see above. The invite must follow all the normal rules. >>>> >>>> Note that as defined, all the usages of the dialog share the same >>> >>> >>> targets. If you have a dialog shared by an invite usage and a >>> subscribe usage, then >>> >>>> either a reinvite or a resubscribe will update the target they >>>> share > >>>> in >>> >>> >>> common. >>> >>> [CHH] I agree. It's still the same dialog, I think, eventhough there >>> seem to be different "usage" of it. But, if you use (re-)INVITE, an >>> SDP offer MUST be included (either in the request or response), >>> according to the normal rules. >> >> >> We are in violent agreement here. >> >>>> If you have just a subscription, and what to change the target, you >>>> can >>> >>> >>> use a resubscribe. No need to use UPDATE or INVITE to accomplish > that. >>> >>> [CHH] I agree. However, my main issue was not so much related to >>> updating of the target, but more to the possibility to add media to >>> an ongoing subscription dialog. >> >> >> IMO the media is a property of an invite dialog usage. You can't add >> media directly to a dialog, you must first add an invite dialog usage >> to the dialog and then it can have media. I don't want to attempt >> drawing a UML diagram here with text art, so I will try to do it with > text: >> >> class: dialog >> attribute: cseq >> attribute: callid >> attribute: to-tag >> attribute: from-tag >> attribute: route set >> attribute: local contact >> attribute: remote contact >> attribute: ... >> subclass: zero or one invite-dialog-usage >> subclass: zero or more subscribe-dialog-usage >> >> class: invite-dialog-usage >> attribute: expiration-time >> attribute: active offer >> attribute: active answer >> attribute: offer/answer state >> attribute: pending offer >> attribute: pending answer >> attribute: zero or more media-session >> attribute: ... >> >> class: subscribe-dialog-usage >> attribute: expiration-time >> attribute: event-type >> attribute: event-parameters >> attribute: event-id >> attribute: direction (watcher/notifier) >> attribute: ... >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 From sip-bounces@ietf.org Wed Mar 01 11:25:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEU6W-0007tI-IG; Wed, 01 Mar 2006 11:23:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEU6U-0007rQ-RC for sip@ietf.org; Wed, 01 Mar 2006 11:23:06 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEU6T-0004lw-J2 for sip@ietf.org; Wed, 01 Mar 2006 11:23:06 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k21GN1qD015907; Wed, 1 Mar 2006 10:23:01 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Mar 2006 16:23:01 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C2907EE@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Dean Willis'" , Sudhir Kumar Reddy Subject: RE: [Sip] query about IMS Date: Wed, 1 Mar 2006 16:22:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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 For 3GPP, it is not just the published documents that are available. Pretty much every document ever submitted to or discussed by 3GPP is available somewhere in this area. regards Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 01 March 2006 16:04 > To: Sudhir Kumar Reddy > Cc: sip@ietf.org > Subject: Re: [Sip] query about IMS > > > Sudhir Kumar Reddy wrote: > > Hi All, > > > > I would like to know is there any forum or mailing list for IMS. > > > > > IMS is mostly defined in 3GPP, and 3GPP2 applies it to CDMA networks. > Both have big web sites with large collections of documents > and dozens > of mailing lists. Active participation in each requires some level of > membership, but their published specifications are avalable > for download. > > http://www.3gpp.org > http://www.3gpp2.org > > -- > 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 Wed Mar 01 12:30:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEV8C-0000Qw-Gu; Wed, 01 Mar 2006 12:28:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEV89-0000HY-JV for sip@ietf.org; Wed, 01 Mar 2006 12:28:54 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEV88-0007Jk-95 for sip@ietf.org; Wed, 01 Mar 2006 12:28:53 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k21HSpLd004167 for ; Wed, 1 Mar 2006 11:28:51 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k21HSpK28940; Wed, 1 Mar 2006 11:28:51 -0600 (CST) Message-ID: <4405D9D2.50503@lucent.com> Date: Wed, 01 Mar 2006 11:28:50 -0600 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: SIP LIST X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Subject: [Sip] I-D on use of TLS 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: , Content-Type: multipart/mixed; boundary="===============1827327681==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1827327681== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050304090003070704040509" This is a cryptographically signed message in MIME format. --------------ms050304090003070704040509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks: I have published a draft with some thoughts on the use of TLS in SIP. The draft itself is organized as a collection of some open issues when using TLS in SIP implementations, and a set of test cases for TLS behavior in SIP entities. I hope the latter may be of use to SIPit. For the former, I apologize a-priori if any of the issues have known solutions in the WG; if they do not, we can start some discussion on them. The URL to access the draft is: http://www.ietf.org/internet-drafts/draft-gurbani-sip-tls-use-00.txt http://www.ietf.org/internet-drafts/draft-gurbani-sip-tls-use-00.html Thank you. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms050304090003070704040509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMDExNzI4NTBaMCMGCSqGSIb3DQEJ BDEWBBQ+POA920hxfrkaZefT7APDkqo7xzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAtRdaKgqiAWQ5UGVvDE+hTmE7ZX0V2B0bznN//qmm0DkkGi4IPSGx yhaTD1YQzLmYyKN3uuDjsKqAUeSOxkvvIleRJx6WdhZOFMBE3jvxZgM0Aozf5X0RCz4XE1MB KeamNe3U9gvO64JaArmUgSfSsznbJJqwsopTlLRhdG+cHbcAAAAAAAA= --------------ms050304090003070704040509-- --===============1827327681== 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 --===============1827327681==-- From sip-bounces@ietf.org Wed Mar 01 17:23:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZh4-000253-Bn; Wed, 01 Mar 2006 17:21:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZh1-0001wH-Pc for sip@ietf.org; Wed, 01 Mar 2006 17:21:11 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEZh1-0000st-H5 for sip@ietf.org; Wed, 01 Mar 2006 17:21:11 -0500 Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k21ML9AP031862 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 1 Mar 2006 16:21:11 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Robert Sparks Date: Wed, 1 Mar 2006 16:21:09 -0600 X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (shaman.nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sip] Addressing the maxforwards issue (SIP work) X-BeenThere: sip@ietf.org X-Mailman-Version: 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 discussions in Vancouver and on list afterwards, we've split the issues and solutions around problems with max-forwards (specifically, the ease of building an amplifying loop in forking proxies) among a few drafts. The first order solution discussed so far is in http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-00.txt http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-00.html (until it appears in the repository) The discussion around max-breadth has been removed to a separate draft and refined. Look for it in sipping. The proposed mechanism for returning more information has also been pulled into a separate draft, contributed as anoter new SIP working group item. Scott Lawrence is editing that document and will be introducing it in a separate message. Also, Dave Oran has repeatedly pointed us at more efficient loop detection algorithms. There is a new individual submission exploring this showing up in the SIPPING working group. 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 Wed Mar 01 18:52:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEb5K-0003tF-Cn; Wed, 01 Mar 2006 18:50:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEb53-0003NV-7Z; Wed, 01 Mar 2006 18:50:05 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEb50-0004vt-LI; Wed, 01 Mar 2006 18:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k21No29W013042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEb50-0000Mh-Bs; Wed, 01 Mar 2006 18:50:02 -0500 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, 01 Mar 2006 18:50:02 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-fork-loop-fix-00.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 : Addressing an Amplification Vulnerability in Forking Proxies Author(s) : R. Sparks, et al. Filename : draft-ietf-sip-fork-loop-fix-00.txt Pages : 9 Date : 2006-3-1 This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-00.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-fork-loop-fix-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-fork-loop-fix-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-1175150.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-fork-loop-fix-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-fork-loop-fix-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-1175150.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 Mar 01 22:54:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEerB-0004p6-6u; Wed, 01 Mar 2006 22:52:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEerA-0004nH-78 for sip@ietf.org; Wed, 01 Mar 2006 22:52:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEer8-0008RE-RV for sip@ietf.org; Wed, 01 Mar 2006 22:52:00 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2006 19:51:58 -0800 X-IronPort-AV: i="4.02,158,1139212800"; d="scan'208"; a="258919683:sNHT32824212" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k223pw1j026208 for ; Wed, 1 Mar 2006 19:51:58 -0800 (PST) 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.211); Wed, 1 Mar 2006 22:51:57 -0500 Received: from [192.168.1.104] ([10.86.240.111]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 22:51:57 -0500 Message-ID: <44066BDD.4050808@cisco.com> Date: Wed, 01 Mar 2006 22:51:57 -0500 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 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2006 03:51:57.0515 (UTC) FILETIME=[A72E81B0:01C63DAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Sip] Re: I-D ACTION:draft-rosenberg-sip-hitchhikers-guide-00.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 The idea behind this draft is to meet one of our charter items, which is to develop a 'roadmap for sip'. There is some precedent for documents like this: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-06.txt Drafts like this are also useful to newcomers for helping find their way through the specs. Even a draft like this is not without open issues. I purposefully omitted a bunch of specifications from being officially part of the sip protocol because they weren't proper SIP extensions - things like object definitions (content indirection, for example). I also omitted framework documents for the most part. Should they be included? Perhaps most controversial will be my choice for what constitutes the 'core sip protocol', the set of specs you basically need to implement to really do sip. There's a P-header on the list... so go take a look. Thanks, Jonathan R. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A Hitchhikers Guide to the Session Initiation Protocol (SIP) > Author(s) : J. Rosenberg > Filename : draft-rosenberg-sip-hitchhikers-guide-00.txt > Pages : 24 > Date : 2006-3-1 > > The Session Initiation Protocol (SIP) is the subject of numerous > specifications that have been produced by the IETF. It can be > difficult to locate the right document, or even to determine the set > of Request for Comments (RFC) about SIP. Don't Panic! This > specification serves as a guide to the SIP RFC series. It lists the > specifications under the SIP umbrella, briefly summarizes each, and > groups them into categories. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchhikers-guide-00.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-rosenberg-sip-hitchhikers-guide-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-rosenberg-sip-hitchhikers-guide-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce -- 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 Mar 01 23:20:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEfGZ-0005yj-Oy; Wed, 01 Mar 2006 23:18:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEfGY-0005yM-9q for sip@ietf.org; Wed, 01 Mar 2006 23:18:14 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEfGW-000141-Tj for sip@ietf.org; Wed, 01 Mar 2006 23:18:14 -0500 Received: from [192.168.0.41] (pool-138-89-78-149.mad.east.verizon.net [138.89.78.149]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k224I6cO001859 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 1 Mar 2006 23:18:07 -0500 (EST) In-Reply-To: <44066BDD.4050808@cisco.com> References: <44066BDD.4050808@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04B7FC37-2DAA-4676-B954-C8141BC29FD5@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Re: I-D ACTION:draft-rosenberg-sip-hitchhikers-guide-00.txt Date: Wed, 1 Mar 2006 23:18:05 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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 This is a great service to the community. For your XXXX list of RFCs in the emergency calling section, it might be useful to add place holders for the emerging ECRIT work. For 3262, one might add that the benefit is particularly small if the underlying transport layer is reliable, e.g., for sips transport. Session timers ... has thus seen -> have thus seen any security considerations on its own. -> of its own One temptation for this draft will be to wait until the very last XXXX has been instantiated. It is not clear that this is wise, but that's probably something to be discussed. Section 14 is somewhat sparse; one wonders if a separate document wouldn't be more appropriate here. On Mar 1, 2006, at 10:51 PM, Jonathan Rosenberg wrote: > The idea behind this draft is to meet one of our charter items, > which is to develop a 'roadmap for sip'. There is some precedent > for documents like this: > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-06.txt > > Drafts like this are also useful to newcomers for helping find > their way through the specs. > > Even a draft like this is not without open issues. I purposefully > omitted a bunch of specifications from being officially part of the > sip protocol because they weren't proper SIP extensions - things > like object definitions (content indirection, for example). I also > omitted framework documents for the most part. Should they be > included? > > Perhaps most controversial will be my choice for what constitutes > the 'core sip protocol', the set of specs you basically need to > implement to really do sip. There's a P-header on the list... so go > take a look. > > Thanks, > Jonathan R. > > Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> Title : A Hitchhikers Guide to the Session Initiation Protocol >> (SIP) >> Author(s) : J. Rosenberg >> Filename : draft-rosenberg-sip-hitchhikers-guide-00.txt >> Pages : 24 >> Date : 2006-3-1 >> >> The Session Initiation Protocol (SIP) is the subject of numerous >> specifications that have been produced by the IETF. It can be >> difficult to locate the right document, or even to determine >> the set >> of Request for Comments (RFC) about SIP. Don't Panic! This >> specification serves as a guide to the SIP RFC series. It >> lists the >> specifications under the SIP umbrella, briefly summarizes each, >> and >> groups them into categories. >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip- >> hitchhikers-guide-00.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-rosenberg-sip-hitchhikers-guide-00.txt". >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow- >> sites.txt >> Internet-Drafts can also be obtained by e-mail. >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-rosenberg-sip-hitchhikers- >> guide-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> --------------------------------------------------------------------- >> --- >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > -- > 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 From sip-bounces@ietf.org Thu Mar 02 00:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEgin-0005ua-1d; Thu, 02 Mar 2006 00:51:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEgil-0005uV-Rr for sip@ietf.org; Thu, 02 Mar 2006 00:51:27 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEgij-0004MQ-Qj for sip@ietf.org; Thu, 02 Mar 2006 00:51:27 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ED7564F0001; Thu, 2 Mar 2006 06:51:24 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 06:51:24 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 06:51:24 +0100 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] Questions on subscription dialogs Date: Thu, 2 Mar 2006 06:51:24 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1AEA@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Questions on subscription dialogs Thread-Index: AcY9SzhxMfhScl6mSqWxiuvRZGp0/AAcW0kA From: "Christer Holmberg \(JO/LMF\)" To: "Robert Sparks" X-OriginalArrivalTime: 02 Mar 2006 05:51:24.0595 (UTC) FILETIME=[57182030:01C63DBD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 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 Hi Robert,=20 >I'm not yet sure exactly what you're looking for the draft to cover wrt the media issue. >Was it specifically an answer to your first question? If not, could you summarize for me? > >The draft talks about dialogs and dialog usages in general. It uses SUBSCRIBE dialogs only as motivating examples. > >To respond to your initial question - as this draft points out, you are asking for a world of interoperability hurt to attempt to create an INVITE usage=20 >inside the SUBSCRIBE usage. Yes - it is legal per 3261, but the general consensus is that it is a really bad idea, and the intent of the dialog-usage=20 >draft is to capture why. The draft does give a general statement, saying that dialog re-usage is a bad idea (I may not fully agree, but that's another issue).=20 I do not believe the draft talks about "INVITE usage inside the SUBSCRIBE usage". Maybe I've missed it, and/or maybe we don't want to describe all "usage combinations", but I don't think it's there. Anyway, I will provide my comments on the draft itself in a separate e-mail, so let's move the discussion there. Regards, Christer On Mar 1, 2006, at 4:11 AM, Christer Holmberg ((JO/LMF)) wrote: > > Hi Jonathan, > > The draft does not currently cover the media issue. But, I think it=20 > SHALL cover it. > > Regards, > > Christer > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 28. helmikuuta 2006 17:14 > To: Paul Kyzivat > Cc: Christer Holmberg (JO/LMF); IETF SIP List > Subject: Re: [Sip] Questions on subscription dialogs > > I think most of the wisdom on dialog usages is captured in: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping- > dialogusage-00.tx > t > > -Jonathan R. > > Paul Kyzivat wrote: > >> Christer, >> >> More in line. Once again we are spelling out the unwritten rules of=20 >> dialogs. >> >> Paul >> >> Christer Holmberg (JO/LMF) wrote: >> >>> Hi Paul, >>> >>> Thanks for your reply! Comments inline ([CHH]). >>> >>>>> Q1: Is it allowed to send non-NOTIFY request within a subscription >>>>> dialog (initiated by SUBSCRIBE), assuming the users support it? >>>>> >>>> >>>> Yes, with limits. In general, a request that is legal outside a=20 >>>> dialog >>> >>> >>> is also legal within a dialog. (E.g. OPTIONS.) In some cases (e.g. >>> >>>> MESSAGE) other limitations have been applied. (You aren't supposed=20 >>>> to >>> >>> >>> use MESSAGE within a dialog as a way to avoid session mode >>> messaging.) >>> >>>> It is legal, though generally discouraged, to send requests within=20 >>>> an >>> >>> >>> existing dialog that establish a new dialog usage. Sending an INVITE >>> within a >>> >>>> dialog established by a SUBSCRIBE falls into this category. >>> >>> >>> >>> [CHH] Is the discouragement documented somewhere? Or, is it just one >>> of the "unwritten rules"? :) >> >> >> I believe it has mostly been written in email threads here. I'm not=20 >> sure if it is enshrined in any RFC or draft. (I think it might be=20 >> mentioned in the target-dialog draft, and I think it might be=20 >> mentioned in a draft by ben or robert.) >> >> I know there was a discussion thread a few months ago about this. I=20 >> was nearly alone in advocating that shared dialogs are not always > evil. >> >>>>> Q2: If Q1=3D=3DTRUE, is it allowed to add media during a = subscription=20 >>>>> dialog, by sending an SDP offer in an UPDATE/re-INVITE? >>>> >>>> >>>> An INVITE in this case (at least the first one) would not be a >>> >>> >>> reINVITE. >>> >>>> It would establish a new invite dialog usage within an already >>> >>> >>> established dialog. >>> >>> [CHH] Well, it would contain a To tag, and I believe it is said=20 >>> somewhere that it then should be treated as a re-INVITE. But, at the >>> end I guess it doesn't matter what we call it, as long as it is=20 >>> allowed to send it. >> >> >> You may be right. The language in 3261 is very sloppy in this regard. >> It implies, but doesn't formalize, the notion of dialog usages, and=20 >> mixes up dialogs and their usages a lot. IMO a reinvite refreshes an=20 >> invite dialog usage. >> >>>> IMO an UPDATE is only permitted within an existing invite dialog > usage. >>> >>> >>> >>>> So you would have to send an INVITE to establish the usage before=20 >>>> you >>> >>> >>> could use UPDATE to do a subsequent offer/answer. >>> >>> [CHH] Where is that said? I was looking in RFC 3311, and eventhough=20 >>> the text examples talk about INVITE initiated dialogs I didn't find=20 >>> any text forbidding it to be used elswhere. But, of course I may=20 >>> have > >>> missed it... >> >> >> I doubt it is said anywhere. Its another thing that has evolved via=20 >> discussion, and enshrined in draft-sawada-sipping-sip-offeranswer-00. >> >>>>>> Q3: If Q2=3D=3DTRUE, is it allowed to use re-INVITE, eventhough = the >>> >>> >>> dialog was not initiated using INVITE? >>> >>>>> See above. Beware that I have heard of no implementation that=20 >>>>> actually >>> >>> >>> support this. >>> >>> [CHH] Neither have I - so far :) >>> >>> >>>>> Q4: If Q1=3D=3DTRUE, if I send an empty re-INVITE within a=20 >>>>> subscription > >>>>> dialog, e.g. to update the remote target, I assume the receiver=20 >>>>> MUST create and include an SDP offer in the 200 OK response,=20 >>>>> eventhough no media has previously been used within the dialog? >>>> >>>> >>>> Again see above. The invite must follow all the normal rules. >>>> >>>> Note that as defined, all the usages of the dialog share the same >>> >>> >>> targets. If you have a dialog shared by an invite usage and a=20 >>> subscribe usage, then >>> >>>> either a reinvite or a resubscribe will update the target they=20 >>>> share > >>>> in >>> >>> >>> common. >>> >>> [CHH] I agree. It's still the same dialog, I think, eventhough there >>> seem to be different "usage" of it. But, if you use (re-)INVITE, an=20 >>> SDP offer MUST be included (either in the request or response),=20 >>> according to the normal rules. >> >> >> We are in violent agreement here. >> >>>> If you have just a subscription, and what to change the target, you >>>> can >>> >>> >>> use a resubscribe. No need to use UPDATE or INVITE to accomplish > that. >>> >>> [CHH] I agree. However, my main issue was not so much related to=20 >>> updating of the target, but more to the possibility to add media to=20 >>> an ongoing subscription dialog. >> >> >> IMO the media is a property of an invite dialog usage. You can't add=20 >> media directly to a dialog, you must first add an invite dialog usage >> to the dialog and then it can have media. I don't want to attempt=20 >> drawing a UML diagram here with text art, so I will try to do it with > text: >> >> class: dialog >> attribute: cseq >> attribute: callid >> attribute: to-tag >> attribute: from-tag >> attribute: route set >> attribute: local contact >> attribute: remote contact >> attribute: ... >> subclass: zero or one invite-dialog-usage >> subclass: zero or more subscribe-dialog-usage >> >> class: invite-dialog-usage >> attribute: expiration-time >> attribute: active offer >> attribute: active answer >> attribute: offer/answer state >> attribute: pending offer >> attribute: pending answer >> attribute: zero or more media-session >> attribute: ... >> >> class: subscribe-dialog-usage >> attribute: expiration-time >> attribute: event-type >> attribute: event-parameters >> attribute: event-id >> attribute: direction (watcher/notifier) >> attribute: ... >> >> _______________________________________________ >> 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 > 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 > > _______________________________________________ > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 02 04:42:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkIF-0008RT-6g; Thu, 02 Mar 2006 04:40:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkID-0008O2-Pr for sip@ietf.org; Thu, 02 Mar 2006 04:40:17 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEkIA-00061b-HF for sip@ietf.org; Thu, 02 Mar 2006 04:40:17 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k229a2D17475 for ; Thu, 2 Mar 2006 04:36:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Mar 2006 03:40:08 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AA4C70F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-sip-hop-limit-diagnostics-00 Thread-Index: AcY8Tpt1viPemlfGSvKyZViv0dhVEABi7Bew From: "Samir Srivastava" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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, 1. Draft proposes=20 "Any 483 response SHOULD be constructed with a message body of type message/sipfrag containing as much as possible of the SIP header from the rejected request." A Proxy receives the request on UDP, and forwards on the TCP , when it receives the response, message becomes more than 1300 bytes (If complete req needs to be copied). Proxy doesn't have TCP transport to send 483 with complete Message. It need to chop down some of the headers. It will be good to provide some guidance on what headers to chop down. Especially via chopping should be done at the last. It is obvious, better it is stated. 2. What B2BUA / SBC will do, there purpose is topology hiding. They will not provide the meaningful guidance as MAX HOP COUNT is reached in the hidden network. It needs to be mentioned somewhere=20 too.=20 Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 02 08:05:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEnSx-0001ar-GI; Thu, 02 Mar 2006 08:03:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDnu8-0007AN-Cu for sip@ietf.org; Mon, 27 Feb 2006 14:19:32 -0500 Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDnu7-0006xY-Mb for sip@ietf.org; Mon, 27 Feb 2006 14:19:32 -0500 Received: (qmail 18082 invoked by uid 510); 27 Feb 2006 14:51:06 -0500 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.142.176):. Processed in 1.098042 secs); 27 Feb 2006 19:51:06 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.176):. Processed in 1.098042 secs Process 18077) Received: from c-24-1-142-176.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.176) by 192.246.69.184 with SMTP; Mon, 27 Feb 2006 19:51:04 +0000 From: "Henry Sinnreich" To: "'Cullen Jennings'" , , "'sipping'" Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering Date: Mon, 27 Feb 2006 14:19:29 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcY7Q6mOhR2LvnfAR2GcDpXGmRTTDQABZDVQAAcVQBQAGvdtQA== X-Antivirus-MYDOMAIN-Message-ID: <114106986583518077@mail.pulver.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ceb20e3ccfd90d068e2ad6c8a4781b53 X-Mailman-Approved-At: Thu, 02 Mar 2006 08:03:34 -0500 Cc: 'Jon Peterson' , 'Allison Mankin' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Message-Id: >In the end, the bulk of the work is done by volunteers that read drafts, >provide ideas and comments, and write the drafts - it the people that >count. I could not agree more, except to add the highest value is added by people who also write code before submitting an I-D written on a word processor. Mybe most of the issues discussed here could be solved by imposing the good old IETF rule "we believe in running code". Writing code first would certainly reduce the avalanche of word processor output that gave us the problems that Dean mentioned. Actually, how much value is there in an I-D that is not backed up by running code? Admittedly there are some framework documents, requirements, etc., but they are the exception to the rule "we believe in running code". Thanks, Henry -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Monday, February 27, 2006 1:18 AM To: sip@ietf.org; sipping Cc: Jon Peterson; Allison Mankin Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering I have written replies to this thread several times - then deleted them :-) It's a hard topic and certainly one that Jon, Allison and I were discussing before this thread. We have talked about it in relation to this thread. We will no doubt be talking about it for some time to come. Below are some questions I have been asking myself. They are really a random stream of conscious. I don't really want answers to them all but if they trigger some thoughts on concrete ideas we can that will help. That is great. I am clearly still in the stage of listening to ideas. Are the chairs the bottleneck that limits the rate? Are the ADs? How can we transfer responsibility from the ADs to chairs? Is the bottleneck to do with the rate that authors update drafts? Is if the bottleneck to do with the rate that comments are provided on the mailing lists? Can having a directorate get this done faster? Can we expand the amount of total work being done or can we only move it around? Do we need more people writing the same number of documents? Can we get new people? How much can we move work around from one topic to another? Will people work on a document they don't care about? why? I hear lots about what documents should be going faster but what documents should be slowed down? Are there whole WGs or topics that we should slow down to zero? There is a large amount of consensus on what document are critical to get done soon. That's surprising. Why? Can we take advantage of that somehow? What's stopping you from getting your drafts done? Is it just time to work on them? Do you need people to review them? Are they held up on other work? What's stopping you from reviewing the drafts you think are important and sending comments? What's stopping you from forcing the the drafts you want finished to get done? If you logically split some WG in two (trying to logical group related thing in each halt), then scheduled them concurrently, would you get twice as much work done or nothing done because everyone who was not there objected to any decision made? The ADs for the RAI WGs right now are Jon and Allison but I've certainly been doing a lot of thinking about this. Let me make a few observations: I would want any change to have some reasonably good chance to make more than a trivial impact. Mostly people work on what they want work on - they vote with their feet. This is a feature not a bug and much better than the alternative. People will work on stuff they don't care about but only to a limited degree. Once things get past WGLC, perhaps Chairs and ADs could be faster but this would not really accelerate things in a huge way. Still worth working on but less clear it can make a huge impact. Having Chairs carefully hound people to work on all the documents that few people care about might only speed up that work at the expense of stuff that is critical. I suspect that for the critical stuff, more hounding is good but there may be a limit. If we think that the sipping chairs are the bottleneck, well hypothetically, we could add another 5 people to the chair list. It's an interesting thought experiment to compare this to adding more groups. I can see several problems with this. Many of the same problems happen by having more working groups. Working groups could have an impact far greater than just more chairs. They allow us to partition time to certain classes of problems - effectively one class per working group - this might help or might not. It might result in a tool to speed up some classes of problems while slowing down others. I think it is reasonably clear that XCON and SIMPLE forking from SIPPING was a good thing. Selecting the right level of decomposition is always a balancing act. If you look at the other IETF directorates, they focus on a particular problem (such as XML, or MIB doctor) and thus can have a handful or two of people. What would we want a directorate here to do? Are we thinking of it as people that could take on an particular draft and help it accelerate it getting done? Would a directorate help this? I believe it might. Jon and I have been talking about this. Could we achieve the same thing some other ways? Would a directorate turn into a group that occasionally went for a nice dinner but did not do much else? I sort of like the directorate idea but I have just not figured out how to get one or more directorates focused enough to help. I have toyed with the idea of asking everyone to periodically focus some fraction of their energy on one key draft for a short period of time and try and get it done. By scheduling these out in time a bit, we might be able to deal with the complain of people not being able to schedule time for when drafts they care about need work. Would this work or be useless? Would it turn out being more or less the same thing as WGLC? Should we try and track the expected schedule for WGLCs across RAI? We have some problems where the solution must intrinsically be entangled across several RAI WGs. Would spending meeting time in a cross RAI meeting help with these? The energy barrier of new work is low. The energy barrier of finishing even simple work is very high. Some of the biggest things I can think of are already underway. The protos makes it so that chairs can do much of what only ADs could do previously. This is good. The formation of RAI allows the ADs to focus more. Anyways, don't read too much into anything I said here other than I'm glad to hear about ideas. In the end, the bulk of the work is done by volunteers that read drafts, provide ideas and comments, and write the drafts - it the people that count. Cullen On 2/26/06 7:02 PM, "Dolly, Martin C, ALABS" wrote: > Hello, > > I do not see where further splitting work into new WGs..etc. solves any > problem. > > I believe that "strong" chairing, and a true "democratic" process, where > not only the voices of the few are heard, will result in faster results. > > Cheers, > > Martin > >> -----Original Message----- >> From: James M. Polk [mailto:jmpolk@cisco.com] >> Sent: Sunday, February 26, 2006 9:15 PM >> To: Rohan Mahy; Dean Willis >> Cc: Cullen Jennings; sip@ietf.org List; Sipping List; Jon Peterson; >> Allison Mankin >> Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of >> Dividingand Conquering >> >> >> Hey >> >> While I was the first to comment on Dean's proposal not >> involving enough >> groups, and the potential for deviding again, I can see the >> flip side of >> this problem being if SIP does exactly what you suggest here: >> limited work >> to 4 or 5 items. >> >> The consequences of that action (or inaction) would be to >> have *more* SDOs >> defining extensions to SIP than is already going on. Many >> people have >> valid new ideas that are shut/stalled out because it takes so >> long to get >> any document done under the best of circumstances. >> >> Venture into this scenario: >> >> Rohan writes a new ID that has zero resistance >> >> Does it become a WG item in the first meeting? >> >> yeah - in SIPPING >> >> that's 6 months of time with zero resistance >> >> In the next meeting it may be moved to SIP for "protocol" >> work to be done >> >> 3 more months, with zero resistance >> >> How long does it take the WG to review the ID? >> >> No one can tell me reaslistically this happens overnight >> because everyone >> has queued the right amount of time to this effort. >> >> so it sits 3 more months >> >> Is this sip-00 version ready for WGLC? >> >> maybe, maybe not >> >> Maybe there is one thing that needs to be adjusted >> >> 3 more months until the next meeting >> >> At the next meeting, *maybe* this ID is ready for WGLC >> >> 2 more weeks >> >> if this is PS track >> >> 2 more weeks for IETF LC >> >> it gets to IESG, does it pass the first time? >> >> If not, that's 2 more weeks >> >> If so, it's 5 months with the RFC-Editor >> >> This adds up to roughly 20 months to get one idea through with >> unrealistically minimal resistance to the idea. >> >> I think this WG has more time on its hands to do more work >> than 4-5 items. >> >> If it takes 4 WGs to have faster milestones on the smaller >> IDs, I think >> that alone is a great idea. >> >> I look forward to a live discussion on this, if it is brought up. >> >> What I'm thinking is happening is more and more SDOs are >> getting tired of >> the IETF taking so long to get docs out. At some point they >> will consider >> the SIP WG irrelevant and do their own thing. >> >> Do we want that? >> >> If giving some of the tasks to other WG chairs to relieve you >> two (Dean and >> Rohan) to get more work done, even if the same number of core >> folks sit in >> each meeting, then I think it is better to get more work done >> with a series >> of WGs having more milestones to meet because there are more chairs >> cracking the whip on authors to get IDs revved and/or reviewed. >> >> >> >> At 04:06 PM 2/26/2006 -0800, Rohan Mahy wrote: >>> Hi, >>> >>> I don't think further splitting is going to solve our >> problems due to the >>> complexity of lateral communication required among groups >> with this much >>> in common. >>> >>> I do think that a working group that describes use cases for >> the RAI area >>> in general could produce some very useful output that has >> been out of >>> scope of individual working groups. The SIP NAT scenarios >> document would >>> be a good candidate to move into such a WG. >>> >>> I think mostly we have a problem saying no. We have too >> much work to do >>> and the only effective way for this community to get better >> throughput is >>> to focus religiously on a much smaller handful of work items >> (ex: 4 or 5) >>> at a time. I am as guilty as the next person for adding new >> milestones >>> (actually, more guilty as a chair), but it is hard to say no >> to new work >>> when old work that is "almost done" takes so long to finish. >>> >>> Perhaps we can have a discussion of this in the RAI area >> open meeting at >>> Dallas. It would be nice to hear the new ADs jump in here >> with their >>> thoughts. Also, Allison has been wrangling this monster longer than >>> anyone except Dean, so I am curious what she has to say. >>> >>> thanks, >>> -rohan >>> >>> >>> On Feb 23, 2006, at 16:30, Dean Willis wrote: >>>> I've been working on SIP and SIPPING and P2P-SIP agendas >> this week, and >>>> that started me thinking. >>>> >>>> We spun up SIPPING to take some of the load off of SIP, and >> in doing so >>>> tried to more narrowly-define the charters of both SIP and SIPPING >>>> relative to the previous SIP charter. >>>> >>>> When we started talking about P2P-SIP, we thought about >> bringing in the >>>> topic as part of SIPPING, but fairly quickly rejected that >> idea because >>>> it was clearly partitionable. >>>> >>>> This started me thinking -- could we further apply this >> principle of >>>> partitioning? >>>> >>>> Both SIP and SIPPING have grown into multi-year monsters, >> each with large >>>> charters and the need for multiple long-sessions at each >> IETF. They're >>>> tricky to chair, require lots of secretarial work, and are >> chronically >>>> late on deliverables (in large part because the chairs are >> acting like >>>> ADs instead of chairs). SPPING, once viewed as the kidney >> of SIP, now >>>> needs its own dialysis. >>>> >>>> Perhaps if we were to split these two working groups into >> three or four >>>> working groups that have much more clearly defined missions >> and scopes, >>>> we could cut them down to one meeting slot each. And if we >> were to have >>>> separate management (chairs and secretaries) for each >> working group, we >>>> could better manage the groups to timely delivery. >>>> >>>> So I'd like to toss out some ideas on how we might >> subdivide, and see how >>>> you folks feel about this. I think the key to any success >> here would be >>>> in scope management. >>>> >>>> What if we had the following groups: >>>> >>>> 1) SIPEM -- SIP Extended Maintenance >>>> >>>> 2) SIPNEW -- New major functionality for SIP >>>> >>>> 3) SIPREQ -- Analysis of requirements raised by new >> applications or SDO >>>> liaison >>>> >>>> 4) SIPUSE -- Using SIP to meet specific application requirements >>>> >>>> >>>> >>>> Here's how we might divide the work: >>>> >>>> >>>> SIPEM >>>> ----- >>>> >>>> Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of >>>> backward-compatible extensions driven by applications with >> near-term >>>> deployment scenarios. >>>> >>>> Initial Milestone Tasks of SIPEM: >>>> >>>> 1) Developing a SIP Guidebook, roughly the equivalent of the TCP >>>> Roadmap, that defines what's "in" SIP and how the pieces >> fit together. >>>> >>>> 2) GRUU >>>> >>>> 3) Outbound >>>> >>>> 4) Target-Dialog >>>> >>>> 5) Certificate Usage >>>> >>>> 6) Location Transport >>>> >>>> 7) Loop Error Correction >>>> >>>> 8) Connected Party Identity >>>> >>>> 9) Hop Limit Diagnostics >>>> >>>> 10) TLS Usage >>>> >>>> 11) Answering Modes >>>> >>>> 12) Connection Reuse >>>> >>>> 13) Rejection of Anonymous Requests >>>> >>>> 14) Consent Mechanism >>>> >>>> >>>> >>>> SIPNEW >>>> ------ >>>> >>>> Scope: Enhancement and evolution of SIP including >> architectural-level >>>> requirements and (as per RFC 3427) extensions without >> requirements for >>>> backward compatibility. >>>> >>>> >>>> Initial milestone tasks of SIPNEW >>>> >>>> 1) Developing a "future roadmap" for the evolution of SIP >>>> >>>> 2) Solving the RFC 3261 Routing Problem >>>> >>>> 3) Use of SAML with SIP >>>> >>>> 4) Response Identity >>>> >>>> 5) Response Authentication >>>> >>>> 6) End to Middle Requests >>>> >>>> >>>> >>>> SIPREQ >>>> ------ >>>> >>>> Scope: Analysis of requirements raised by new applications >> of SIP in IETF >>>> or in external SDOs (as per RFC 3427). Development of >> requirements for >>>> changes to SIP or for usage guides in response to applications >>>> requirements. Another way of wording this would be "problem >> definition". >>>> >>>> Initial milestones and tasks of SIPREQ: >>>> >>>> 1) Session Policy Requirements >>>> >>>> >>>> >>>> SIPUSE >>>> ------ >>>> >>>> Scope: Guidance on how to use existing SIP specifications >> and mechanisms >>>> including examples, call flows, test cases, error >> avoidance, and so on. >>>> Review (as per RFC 3427) of SIP Event Packages. >>>> >>>> >>>> Initial milestones and tasks for SIPUSE: >>>> >>>> 1) Service Examples >>>> >>>> 2) Security Examples >>>> >>>> 3) Race Condition Examples >>>> >>>> 4) Session media policy mechanism >>>> >>>> 5) Session policy package mechanism >>>> >>>> 6) Service quality reporting mechanism >>>> >>>> 7) URI List mechanism >>>> >>>> 8) Subscriptions to Ad-Hoc Resource Lists mechanism >>>> >>>> 9) Multiple REFER mechanism >>>> >>>> 10) Ad-Hoc Conferencing using URI lists mechanism >>>> >>>> 11) Call Control Transfer mechanism >>>> >>>> 12) Configuration Delivery mechanism >>>> >>>> 13) Emergency Calling using SIP (SOS) mechanism >>>> >>>> >>>> >>>> >>>> Note that I'm not entirely happy with the division of >> SIPPING into SIPUSE >>>> and SIPREQ. While it seems like we spend a lot of time in SIPPING >>>> debating requirements, there are currently a lot of >> deliverables in this >>>> category. >>>> >>>> >>>> -- >>>> 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 >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 >> _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 02 08:26:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEnnh-0005rl-Cp; Thu, 02 Mar 2006 08:25:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEnnf-0005rQ-Gs for sip@ietf.org; Thu, 02 Mar 2006 08:24:59 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEnne-0005ov-RD for sip@ietf.org; Thu, 02 Mar 2006 08:24:59 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2EB384F0065 for ; Thu, 2 Mar 2006 14:24:58 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 14:24:57 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 14:24:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Mar 2006 14:24:57 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B0A@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OUTBOUND: How far does a request go? Thread-Index: AcY9/LMsdoCsLjKaQsOqGbpe/Gy/og== From: "Christer Holmberg \(JO/LMF\)" To: "IETF SIP List" X-OriginalArrivalTime: 02 Mar 2006 13:24:57.0720 (UTC) FILETIME=[B3617780:01C63DFC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [Sip] OUTBOUND: How far does a request go? X-BeenThere: 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="===============0313430962==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0313430962== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63DFC.B33F262A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63DFC.B33F262A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One thing, which I haven't seen being discussed in the "Outbound and STUN Keep Alive" thread: Assuming we DO use a SIP method to keep the NAT binding open, the questions is whether the request should be terminated by an edge proxy "on the other side" (from a UA perspective) of the NAT, or if the request should go all the way to the registrar (scenario shown in chapter 4.3 of the draft). In IMS, the edge proxy would be the P-CSCF, while the S-CSCF would be the registrar. I am not sure one would like to require the P-CSCF to forward the NAT keep-alive requests towards the S-CSCF, because it would only cause unecessary extra traffic in the IMS network. So, for this reason methods like OPTIONS cannot be used, because OPTIONS WILL be forwarded by a P-CSCF. So, either the edge proxy must know that it can terminate certain requests, OR the requests must be addressed to the edge proxy itself (instead of the registrar). And, IF we assume there is no proxy between the UA and the NAT, the double CRLF "proxy problem" would not be an issue, since no proxy would be supposed to forward the double CRLF. Of course, there may still exist other issues with the double CRLF mechanism. A STUN request would also be terminated by the edge proxy on the other side, I assume. And, if there IS a proxy between the UA and the NAT, I guess that proxy would have to send the double CRLFs. I don't really see a difference whether whatever-we-come-up-with has to be implemented in the UAs, or in the proxy between the UA and the NAT... Regards, Christer ------_=_NextPart_001_01C63DFC.B33F262A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OUTBOUND: How far does a request go?

Hi,

One thing, which I haven't seen being = discussed in the "Outbound and STUN Keep Alive" thread:

Assuming we DO use a SIP method to keep = the NAT binding open, the questions is whether the request should be = terminated by an edge proxy "on the other side" (from a UA = perspective) of the NAT, or if the request should go all the way to the = registrar (scenario shown in chapter 4.3 of the draft).

In IMS, the edge proxy would be the = P-CSCF, while the S-CSCF would be the registrar. I am not sure one would = like to require the P-CSCF to forward the NAT keep-alive requests = towards the S-CSCF, because it would only cause unecessary extra traffic = in the IMS network. So, for this reason methods like OPTIONS cannot be = used, because OPTIONS WILL be forwarded by a P-CSCF. So, either the edge = proxy must know that it can terminate certain requests, OR the requests = must be addressed to the edge proxy itself (instead of the = registrar).

And, IF we assume there is no proxy = between the UA and the NAT, the double CRLF "proxy problem" = would not be an issue, since no proxy would be supposed to forward the = double CRLF. Of course, there may still exist other issues with the = double CRLF mechanism. A STUN request would also be terminated by the = edge proxy on the other side, I assume.

And, if there IS a proxy between the UA = and the NAT, I guess that proxy would have to send the double CRLFs. I = don't really see a difference whether whatever-we-come-up-with has to be = implemented in the UAs, or in the proxy between the UA and the = NAT...

Regards,

Christer

------_=_NextPart_001_01C63DFC.B33F262A-- --===============0313430962== 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 --===============0313430962==-- From sip-bounces@ietf.org Thu Mar 02 09:50:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEp6O-0003nu-Fz; Thu, 02 Mar 2006 09:48:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEp6N-0003nV-Ek for sip@ietf.org; Thu, 02 Mar 2006 09:48:23 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEp6L-0000uW-Id for sip@ietf.org; Thu, 02 Mar 2006 09:48:22 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 2D9786C017; Thu, 2 Mar 2006 09:48:21 -0500 (EST) Subject: Re: [Sip] Addressing the maxforwards issue (SIP work) From: Scott Lawrence To: Robert Sparks In-Reply-To: References: Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 02 Mar 2006 09:48:20 -0500 Message-Id: <1141310900.3381.21.camel@cdhcp132.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 On Wed, 2006-03-01 at 16:21 -0600, Robert Sparks wrote: > The proposed mechanism for returning more information has also been > pulled into a separate draft, contributed as anoter new SIP working > group > item. Scott Lawrence is editing that document and will be > introducing > it in > a separate message. That draft has also been submitted, and is available now at: http://scm.sipfoundry.org/rep/ietf-drafts/lawrence/hopcopy/draft-ietf-sip-hop-limit-diagnostics-00.html http://scm.sipfoundry.org/rep/ietf-drafts/lawrence/hopcopy/draft-ietf-sip-hop-limit-diagnostics-00.txt -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com Consulting Engineer - Pingtel Corp. http://www.pingtel.com/ sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 02 09:56:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpCk-00042h-Ua; Thu, 02 Mar 2006 09:54:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpCk-00042b-Bh for sip@ietf.org; Thu, 02 Mar 2006 09:54:58 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEpCk-00019W-2Y for sip@ietf.org; Thu, 02 Mar 2006 09:54:58 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id C9B316C017; Thu, 2 Mar 2006 09:54:57 -0500 (EST) Subject: Re: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 From: Scott Lawrence To: Samir Srivastava In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60AA4C70F@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60AA4C70F@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 02 Mar 2006 09:54:57 -0500 Message-Id: <1141311297.3381.28.camel@cdhcp132.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Thu, 2006-03-02 at 03:40 -0600, Samir Srivastava wrote: > 1. Draft proposes > "Any 483 response SHOULD be constructed with a message body of > type > message/sipfrag containing as much as possible of the SIP header > from the rejected request." > > A Proxy receives the request on UDP, and forwards on the TCP , when it > receives the response, message becomes more than 1300 bytes (If complete > req needs to be copied). Proxy doesn't have TCP transport to send 483 > with complete Message. It need to chop down some of the headers. It will > be good to provide some guidance on what headers to chop down. > Especially via chopping should be > done at the last. It is obvious, better it is stated. > > 2. What B2BUA / SBC will do, there purpose is topology hiding. They will > not provide the meaningful > guidance as MAX HOP COUNT is reached in the hidden network. It needs > to be mentioned somewhere > too. The latter is addressed in the Security Considerations section: 4. Security Considerations The proposed mechanism provides a means by which topology and some routing information about a set of SIP systems can be discovered. The mechanism is very similar to that provided for IP routing by the traceroute tool. Some systems may not want to expose as much information as is available in the full set of SIP request headers by returning them in the error response body. It is suggested in this case that at least all of the Route and Via headers from the request be returned in the message/sipfrag body. In the example (Section 2.3), this would at least enable the end user to determine which proxies were in the routing loop and how the request arrived there, but not the specific address transformations that caused the loop. I suppose that if a system wanted prune the response to fit into 1300 bytes, the recommendation about what to trim would be the same. If the consensus is it wouldb be better to move that to a section of its own and then reference it for both purposes, that would be an easy change. When are we going to all just agree that reassembling UDP is essential and get it done? -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com Consulting Engineer - Pingtel Corp. http://www.pingtel.com/ sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 02 09:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpDC-0004bg-U1; Thu, 02 Mar 2006 09:55:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpDB-0004YK-2u for sip@ietf.org; Thu, 02 Mar 2006 09:55:25 -0500 Received: from zproxy.gmail.com ([64.233.162.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEpD9-0001AZ-Qt for sip@ietf.org; Thu, 02 Mar 2006 09:55:25 -0500 Received: by zproxy.gmail.com with SMTP id z31so441712nzd for ; Thu, 02 Mar 2006 06:55:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YOv7c3h4q6AktyHY+BVAl+EauHmPt63Uij1Fx4bNLh1sLB55APjZ/G5PfRgB/BVmPBw72wkre7hSZ8BPNFvzQTzT1tapEvXmtfEbGJBbvsBnaWM05KhKEjyaftRkilSio0OH1vSiH0fP3/UV1BFJwIYfnPG06yoanaSF4BGdosc= Received: by 10.64.233.2 with SMTP id f2mr700493qbh; Thu, 02 Mar 2006 06:55:23 -0800 (PST) Received: by 10.65.214.4 with HTTP; Thu, 2 Mar 2006 06:55:23 -0800 (PST) Message-ID: Date: Thu, 2 Mar 2006 20:25:23 +0530 From: "sai t" To: "Sudhir Kumar Reddy" Subject: Re: [Sip] Query presence through polling In-Reply-To: <52db68bc0602232149s29e17b67w38226918a3f9ef03@mail.gmail.com> MIME-Version: 1.0 References: <52db68bc0602232149s29e17b67w38226918a3f9ef03@mail.gmail.com> X-Spam-Score: 0.1 (/) 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: , Content-Type: multipart/mixed; boundary="===============0924913468==" Errors-To: sip-bounces@ietf.org --===============0924913468== Content-Type: multipart/alternative; boundary="----=_Part_8273_7563822.1141311323264" ------=_Part_8273_7563822.1141311323264 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Sudhir, refer to the RFC 3265 section 3.3.6 and section 3.1.1 paragrpah before last paragraph Regards, Sai Reddy On 2/24/06, Sudhir Kumar Reddy wrote: > > Hi All, > > Is there any draft or RFC for reterieving the Presence through polling? > > > any feedback is appericated. > > thanks in advance > > best regards > Sudhir > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > ------=_Part_8273_7563822.1141311323264 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Sudhir,
         
            refer to the RFC 3265 section 3.3.6 and section 3.1.1 paragrpah before last paragraph
Regards,
Sai Reddy


On 2/24/06, Sudhir Kumar Reddy <t.sudhirkumar@gmail.com> wrote:
Hi All,
 
Is there any draft or RFC for reterieving the Presence through polling= ?
 
 
any feedback is appericated.
 
thanks in advance
 
best regards
Sudhir

_______________________________________________
Sip mai= ling list  http= s://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for qu= estions on current sip
Use sipping@ietf.org for new developments on the = application of sip


------=_Part_8273_7563822.1141311323264-- --===============0924913468== 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 --===============0924913468==-- From sip-bounces@ietf.org Thu Mar 02 11:12:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqNQ-0005u5-23; Thu, 02 Mar 2006 11:10:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqNO-0005u0-SR for sip@ietf.org; Thu, 02 Mar 2006 11:10:02 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqNN-0004Ha-E1 for sip@ietf.org; Thu, 02 Mar 2006 11:10:02 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k22G9trY019723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Mar 2006 17:09:56 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k22G9o0X025775; Thu, 2 Mar 2006 17:09:50 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k22G9eIT025773; Thu, 2 Mar 2006 17:09:40 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] Addressing the maxforwards issue (SIP work) From: Hans Persson To: Scott Lawrence In-Reply-To: <1141310900.3381.21.camel@cdhcp132.pingtel.com> References: <1141310900.3381.21.camel@cdhcp132.pingtel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Thu, 02 Mar 2006 17:09:40 +0100 Message-Id: <1141315780.13702.43.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Thu, 02 Mar 2006 17:09:57 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 tor 2006-03-02 klockan 09:48 -0500 skrev Scott Lawrence: > On Wed, 2006-03-01 at 16:21 -0600, Robert Sparks wrote: > > The proposed mechanism for returning more information has also been > > pulled into a separate draft, contributed as anoter new SIP working > > group item. I think this looks like a good idea. In section 2, it says "When a SIP User Agent receives a request whose Max-Forwards is zero, it returns a 483 error response [...]". Surely this should read "SIP proxy"? I know that there are many systems where the administrator won't want any kind of information like this (topology, etc) to leak outside the enterprise perimeter, but then the requirement to add the stuff in the body is only a SHOULD, so I have no problem with this. Nits: Page 2, third paragraph: remove "another" on first line. Section 2, second paragraph: "authors" -> "authors'". Page 7, last paragraph: "its'" -> "its". Section 2.4: "and have explicitly" -> "and has been explicitly". Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 02 12:58:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEs2i-0001zt-Li; Thu, 02 Mar 2006 12:56:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEs2g-0001x0-Pr for sip@ietf.org; Thu, 02 Mar 2006 12:56:46 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEs2f-0000QZ-Fm for sip@ietf.org; Thu, 02 Mar 2006 12:56:46 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k22Hurtq010345 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 2 Mar 2006 11:56:54 -0600 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B0A@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1B0A@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] OUTBOUND: How far does a request go? Date: Thu, 2 Mar 2006 11:56:33 -0600 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 On Mar 2, 2006, at 7:24 AM, Christer Holmberg ((JO/LMF)) wrote: > One thing, which I haven't seen being discussed in the "Outbound > and STUN Keep Alive" thread: > > Assuming we DO use a SIP method to keep the NAT binding open, the > questions is whether the request should be terminated by an edge > proxy "on the other side" (from a UA perspective) of the NAT, or if > the request should go all the way to the registrar (scenario shown > in chapter 4.3 of the draft). > > In IMS, the edge proxy would be the P-CSCF, while the S-CSCF would > be the registrar. I am not sure one would like to require the P- > CSCF to forward the NAT keep-alive requests towards the S-CSCF, > because it would only cause unecessary extra traffic in the IMS > network. So, for this reason methods like OPTIONS cannot be used, > because OPTIONS WILL be forwarded by a P-CSCF. So, either the edge > proxy must know that it can terminate certain requests, OR the > requests must be addressed to the edge proxy itself (instead of the > registrar). > > And, IF we assume there is no proxy between the UA and the NAT, the > double CRLF "proxy problem" would not be an issue, since no proxy > would be supposed to forward the double CRLF. Of course, there may > still exist other issues with the double CRLF mechanism. A STUN > request would also be terminated by the edge proxy on the other > side, I assume. > > And, if there IS a proxy between the UA and the NAT, I guess that > proxy would have to send the double CRLFs. I don't really see a > difference whether whatever-we-come-up-with has to be implemented > in the UAs, or in the proxy between the UA and the NAT... If we get into the use case of "there is a NAT between the edge proxy and the registrar", then we have a problem if the edge proxy terminates the keepalive. I currently believe that this is a separate case, and that edge proxies may well need to do continuity checking to their upstream proxies and perhaps do something like "outbound" along with connection reuse, but people have raised the case in the context of the current draft (which touches on it, I believe). -- 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 Mar 02 13:17:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsL9-000634-LT; Thu, 02 Mar 2006 13:15:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsL7-00062z-U2 for sip@ietf.org; Thu, 02 Mar 2006 13:15:49 -0500 Received: from web8613.mail.in.yahoo.com ([202.43.219.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEsL5-00011i-RT for sip@ietf.org; Thu, 02 Mar 2006 13:15:49 -0500 Received: (qmail 83637 invoked by uid 60001); 2 Mar 2006 18:15:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hw9IKFBggfAVucqgFz9a6VCYZbQHAafd6Cq4gqiGDRBKPVf8MSRkhKI6DJVEa9CENjCAHgOlA/wAb87Htvmh1gK6bPyTMFRRFSicVCRPtFWum9atfscCJSe51yGl0kjPEDDvf7H2D9ce7Za0cJ7eJxMdZChWUBw5MQoid1/le/k= ; Message-ID: <20060302181544.83635.qmail@web8613.mail.in.yahoo.com> Received: from [210.214.40.209] by web8613.mail.in.yahoo.com via HTTP; Thu, 02 Mar 2006 18:15:44 GMT Date: Thu, 2 Mar 2006 18:15:44 +0000 (GMT) From: Thejeswara Reddy To: sip ietf MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Sip] sip over T/TCP X-BeenThere: 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="===============1524860588==" Errors-To: sip-bounces@ietf.org --===============1524860588== Content-Type: multipart/alternative; boundary="0-817182168-1141323344=:82966" Content-Transfer-Encoding: 8bit --0-817182168-1141323344=:82966 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hai, can SIP used over T/TCP ? >>>>>>>as T/TCP has advatageous over TCP and UDP is there any limitations ? thanks theja --------------------------------- Jiyo cricket on Yahoo! India cricket Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-817182168-1141323344=:82966 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hai,
can SIP used over T/TCP ?
>>>>>>>as T/TCP  has advatageous over TCP and UDP
is there any limitations ?

thanks
theja

Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-817182168-1141323344=:82966-- --===============1524860588== 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 --===============1524860588==-- From sip-bounces@ietf.org Thu Mar 02 14:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEt9d-0001hU-OV; Thu, 02 Mar 2006 14:08:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEt9b-0001hJ-UB for sip@ietf.org; Thu, 02 Mar 2006 14:07:59 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEt9Y-00035b-Ju for sip@ietf.org; Thu, 02 Mar 2006 14:07:59 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k22J7ro10753; Thu, 2 Mar 2006 14:07:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 Date: Thu, 2 Mar 2006 13:07:43 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AABE56C@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 Thread-Index: AcY+CUlNW4ZM79qCQSe3pvdwS6OWTAAIwFWQ From: "Samir Srivastava" To: "Scott Lawrence" 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: , Errors-To: sip-bounces@ietf.org IMHO, Please add proxy pruning too. If It need to truncate via/RR also, can we show in the body that response is truncated one ?? Thx Samir -----Original Message----- From: Scott Lawrence [mailto:slawrence@pingtel.com]=20 Sent: Thursday, March 02, 2006 6:55 AM To: Srivastava, Samir [SC100:8826:EXCH] Cc: sip@ietf.org Subject: Re: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 On Thu, 2006-03-02 at 03:40 -0600, Samir Srivastava wrote: > 1. Draft proposes=20 > "Any 483 response SHOULD be constructed with a message body of=20 > type > message/sipfrag containing as much as possible of the SIP header > from the rejected request." >=20 > A Proxy receives the request on UDP, and forwards on the TCP , when=20 > it receives the response, message becomes more than 1300 bytes (If=20 > complete req needs to be copied). Proxy doesn't have TCP transport to=20 > send 483 with complete Message. It need to chop down some of the=20 > headers. It will be good to provide some guidance on what headers to chop down. > Especially via chopping should be > done at the last. It is obvious, better it is stated. >=20 > 2. What B2BUA / SBC will do, there purpose is topology hiding. They=20 > will not provide the meaningful > guidance as MAX HOP COUNT is reached in the hidden network. It=20 > needs to be mentioned somewhere > too.=20 The latter is addressed in the Security Considerations section: 4. Security Considerations The proposed mechanism provides a means by which topology and some routing information about a set of SIP systems can be discovered. The mechanism is very similar to that provided for IP routing by the traceroute tool. Some systems may not want to expose as much information as is available in the full set of SIP request headers by returning them in the error response body. It is suggested in this case that at least all of the Route and Via headers from the request be returned in the message/sipfrag body. In the example (Section 2.3), this would at least enable the end user to determine which proxies were in the routing loop and how the request arrived there, but not the specific address transformations that caused the loop. I suppose that if a system wanted prune the response to fit into 1300 bytes, the recommendation about what to trim would be the same. If the consensus is it wouldb be better to move that to a section of its own and then reference it for both purposes, that would be an easy change. When are we going to all just agree that reassembling UDP is essential and get it done?=20 -- Scott Lawrence tel:+1-781-938-5306;ext=3D162 or = sip:slawrence@pingtel.com Consulting Engineer - Pingtel Corp. http://www.pingtel.com/ sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 02 15:41:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuZs-0004nL-LS; Thu, 02 Mar 2006 15:39:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuZs-0004nG-2S for sip@ietf.org; Thu, 02 Mar 2006 15:39:12 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEuZq-0006Y5-N4 for sip@ietf.org; Thu, 02 Mar 2006 15:39:12 -0500 Received: from [64.101.173.216] ([64.101.173.216]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k22KdO79010882 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 2 Mar 2006 14:39:25 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 2 Mar 2006 14:39:04 -0600 To: IETF SIP List X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Orit Levin Subject: [Sip] draft-ietf-sip-refer-feature-param approved by 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 Congratulations on yet another finished milestone. -- 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 Mar 02 15:46:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuew-0000B6-6l; Thu, 02 Mar 2006 15:44:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEueu-0000Ab-Uw for sip@ietf.org; Thu, 02 Mar 2006 15:44:24 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEuet-0006eG-Kg for sip@ietf.org; Thu, 02 Mar 2006 15:44:24 -0500 Received: from [64.101.173.216] ([64.101.173.216]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k22KiboO010972 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 2 Mar 2006 14:44:38 -0600 In-Reply-To: <20060302181544.83635.qmail@web8613.mail.in.yahoo.com> References: <20060302181544.83635.qmail@web8613.mail.in.yahoo.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96C0E142-546C-4DB6-8B69-A9618075816A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] sip over T/TCP Date: Thu, 2 Mar 2006 14:44:20 -0600 To: Thejeswara Reddy X-Mailer: Apple Mail (2.746.2) 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 On Mar 2, 2006, at 12:15 PM, Thejeswara Reddy wrote: > hai, > can SIP used over T/TCP ? > >>>>>>>as T/TCP has advatageous over TCP and UDP > is there any limitations ? I'm not aware of any fundamental reason it wouldn't work, but I'm not aware of any work documenting the details. We have documented usage with TCP, UDP, and SCTP. A T/TCP binding would make a good senior or master's project, I think. Given the limited deployment of T/TCP, it would probably be out of scope for this working group, or the SIPPING working group. -- 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 Mar 02 17:18:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEw5k-0004Kj-M8; Thu, 02 Mar 2006 17:16:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEw5j-0004C5-50 for sip@ietf.org; Thu, 02 Mar 2006 17:16:11 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEvFH-0003UY-Ro for sip@ietf.org; Thu, 02 Mar 2006 16:21:59 -0500 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEv9f-000331-MR for sip@ietf.org; Thu, 02 Mar 2006 16:16:13 -0500 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:343a]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k22LG9Ma024067; Thu, 2 Mar 2006 22:16:09 +0100 (CET) Message-ID: <4407608F.1020305@netlab.hut.fi> Date: Thu, 02 Mar 2006 23:15:59 +0200 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] sip over T/TCP References: <20060302181544.83635.qmail@web8613.mail.in.yahoo.com> <96C0E142-546C-4DB6-8B69-A9618075816A@softarmor.com> In-Reply-To: <96C0E142-546C-4DB6-8B69-A9618075816A@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.6 (--) 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 It may not actually be something you'd want to get involved with after discouraging the use of UDP. To quote draft-ietf-tcpm-tcp-roadmap-05 [p.18] RFC 1644 E "T/TCP -- TCP Extensions for Transactions Functional Specification" (July 1994) - found defective The inventors of TCP believed that cached connection state could have been used to eliminate TCP's 3-way handshake, to support two- packet request/response exchanges. RFCs 1379 [RFC1379] and 1644 [RFC1644] show that this is far from simple. Furthermore, T/TCP floundered on the ease of denial-of-service attacks that can result. One idea pioneered by T/TCP lives on in RFC 2140, in the sharing of state across connections. Maybe a master project can study if and/or how bad this is for SIP. Joerg > > On Mar 2, 2006, at 12:15 PM, Thejeswara Reddy wrote: > >> hai, >> can SIP used over T/TCP ? >> >>>>>>>as T/TCP has advatageous over TCP and UDP >> is there any limitations ? > > > I'm not aware of any fundamental reason it wouldn't work, but I'm not > aware of any work documenting the details. We have documented usage > with TCP, UDP, and SCTP. > > A T/TCP binding would make a good senior or master's project, I think. > Given the limited deployment of T/TCP, it would probably be out of > scope for this working group, or the SIPPING working group. > > -- > 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 Mar 02 17:38:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEwPk-0005P0-MQ; Thu, 02 Mar 2006 17:36:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEwPj-0005Ia-1h for sip@ietf.org; Thu, 02 Mar 2006 17:36:51 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEwPi-0000f2-O5 for sip@ietf.org; Thu, 02 Mar 2006 17:36:51 -0500 Received: from [64.101.173.216] ([64.101.173.216]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k22Mb5vJ011731 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 2 Mar 2006 16:37:06 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip ietf From: Dean Willis Date: Thu, 2 Mar 2006 16:36:47 -0600 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] draft ietf-sip-target-dialog provisionally approved by IESG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Congratulations yet again. The target-dialog draft has been approved by the IESG. Final announcement is pending an AD writeup to fix a couple of nits with Instructions to the RFC Editor. One of these nits is that the draft uses RFC 2119 language (MUST), but failed to include a reference to 2119, which it MUST do. Something to watch for in future drafts -- idnits currently doesn'n't catch this, and I've asked Henrik to look into adding this in a future idnist rev. -- 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 Mar 02 23:43:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF26l-0004lX-TK; Thu, 02 Mar 2006 23:41:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF26k-0004lS-NK for sip@ietf.org; Thu, 02 Mar 2006 23:41:38 -0500 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF26j-0002Bb-A4 for sip@ietf.org; Thu, 02 Mar 2006 23:41:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Mar 2006 06:41:26 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606551CE3F7@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New ID on route management in SIP Thread-Index: AcY+VP0V4Khig4ftSOmnWoHVG/aFDQ== From: "David Schwartz" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Sip] New ID on route management 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: , Content-Type: multipart/mixed; boundary="===============1680542944==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1680542944== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63E7C.C107820F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63E7C.C107820F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello. =20 There have been some problems with the posting of an ID I wrote so I will send a link to the list for review while the other issues are sorted out. =20 http://www.kayote.com/web/docs/Drafts/draft-schwartz-sip-route -management-00.txt Basically, the ID is a framework that discusses the need for better mechanisms to secure end to end routes/vias/path headers. While there has been some discussion of these issues in the past - the solutions offered were incomplete and usually addressed only one part of the problem. While identity has received much deserved attention it is still far to easy to wreak havoc on end to end routing in SIP. While many network operators employ hacks to deal with these I believe it is about time we discussed better approaches. While we have had success with one particular solution we deployed in our network, my goal in Dallas is not to push one approach or another, rather it is to agree that there is a problem and to agree to discuss the solution set. I hope to present real life examples from our network of some of the more clever attacks we have seen. I am sure these will be of benefit to the community. Cheers, David ------_=_NextPart_001_01C63E7C.C107820F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello.
 
There = have been some=20 problems with the posting of an ID I wrote so I will send a link to the = list for=20 review while the other issues are sorted out.
 

<= U>http://www.kayote.com/web/docs/Drafts/draft-schwartz-sip-rou= te-management-00.txt

Basically, the ID is a=20 framework that discusses the need for better mechanisms to secure end to = end=20 routes/vias/path headers. While there has been some discussion of these = issues=20 in the past - the solutions offered were incomplete and usually = addressed only=20 one part of the problem. While identity has received much deserved=20 attention it is still far to easy to wreak havoc on end to end routing = in SIP.=20 While many network operators employ hacks to deal with these I believe = it is=20 about time we discussed better approaches.

While we = have had=20 success with one particular solution we deployed in our network, my goal = in=20 Dallas is not to push one approach or another, rather it is to agree = that there=20 is a problem and to agree to discuss the solution set. I hope to present = real=20 life examples from our network of some of the more clever attacks we = have seen.=20 I am sure these will be of benefit to the community.

Cheers,

David

------_=_NextPart_001_01C63E7C.C107820F-- --===============1680542944== 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 --===============1680542944==-- From sip-bounces@ietf.org Fri Mar 03 02:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF4ap-00026P-3D; Fri, 03 Mar 2006 02:20:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF4an-00023w-NU for sip@ietf.org; Fri, 03 Mar 2006 02:20:49 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF4al-0008J4-Se for sip@ietf.org; Fri, 03 Mar 2006 02:20:49 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 07FBC775; Fri, 3 Mar 2006 08:20:47 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 08:20:46 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 08:20:46 +0100 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] OUTBOUND: How far does a request go? Date: Fri, 3 Mar 2006 08:20:45 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B11@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] OUTBOUND: How far does a request go? Thread-Index: AcY+JnvATsd3ZwgjRZC5R1wJUu87wQAa8xPQ From: "Christer Holmberg \(JO/LMF\)" To: "Dean Willis" X-OriginalArrivalTime: 03 Mar 2006 07:20:46.0004 (UTC) FILETIME=[FD27F740:01C63E92] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Dean,=20 > One thing, which I haven't seen being discussed in the "Outbound and=20 > STUN Keep Alive" thread: > > Assuming we DO use a SIP method to keep the NAT binding open, the=20 > questions is whether the request should be terminated by an edge proxy > "on the other side" (from a UA perspective) of the NAT, or if the=20 > request should go all the way to the registrar (scenario shown in=20 > chapter 4.3 of the draft). > > In IMS, the edge proxy would be the P-CSCF, while the S-CSCF would be=20 > the registrar. I am not sure one would like to require the P- CSCF to=20 > forward the NAT keep-alive requests towards the S-CSCF, because it=20 > would only cause unecessary extra traffic in the IMS network. So, for=20 > this reason methods like OPTIONS cannot be used, because OPTIONS WILL=20 > be forwarded by a P-CSCF. So, either the edge proxy must know that it=20 > can terminate certain requests, OR the requests must be addressed to=20 > the edge proxy itself (instead of the registrar). > > And, IF we assume there is no proxy between the UA and the NAT, the=20 > double CRLF "proxy problem" would not be an issue, since no proxy=20 > would be supposed to forward the double CRLF. Of course, there may=20 > still exist other issues with the double CRLF mechanism. A STUN=20 > request would also be terminated by the edge proxy on the other side,=20 > I assume. > > And, if there IS a proxy between the UA and the NAT, I guess that=20 > proxy would have to send the double CRLFs. I don't really see a=20 > difference whether whatever-we-come-up-with has to be implemented in=20 > the UAs, or in the proxy between the UA and the NAT... If we get into the use case of "there is a NAT between the edge proxy and the registrar", then we have a problem if the edge proxy terminates the keepalive. [CHH] The use-case I had in mind is when we have a NAT between a proxy and the edge proxy. The edge proxy would then terminate the keep-alive messages, send by the UAs AND/OR the proxy behind the NAT. Maybe we should use different terms for the proxies we are talking about, depending on where they are located, in order to avoid confusion and missunderstandings... 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 Mar 03 06:39:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF8b8-0006yE-MZ; Fri, 03 Mar 2006 06:37:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF8b7-0006we-2X for sip@ietf.org; Fri, 03 Mar 2006 06:37:25 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF8b6-0000cO-AU for sip@ietf.org; Fri, 03 Mar 2006 06:37:25 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 773FA4F0096; Fri, 3 Mar 2006 12:37:23 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 12:37:22 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 12:37:22 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Mar 2006 12:37:22 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B1D@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dialog usage: Forking impacts Thread-Index: AcY+ttXlJJDAvvtEQJejfg2S+gog5g== From: "Christer Holmberg \(JO/LMF\)" To: "IETF SIP List" , "Robert Sparks" , "Paul Kyzivat" X-OriginalArrivalTime: 03 Mar 2006 11:37:22.0788 (UTC) FILETIME=[D65AC240:01C63EB6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [Sip] Dialog usage: Forking impacts X-BeenThere: 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="===============0856588650==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0856588650== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63EB6.D5E8709A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63EB6.D5E8709A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Another scenario related to the dialog usage issue: 1. UA_1 sends an INVITE, which gets forked to UA_2 and UA_3.=20 2. UA_2 establish an early dialog with UA_1 and sends a SUBSCRIBE (or any other request establishing a new dialog usage) to UA_1, establishing a dialog usage (subscribe dialog usage in case of SUBSCRIBE). 3. UA_3 acceptes the session for the INVITE and sends 200 OK (INVITE) 4. The forking proxy sends a CANCEL to UA_2, and forwards the 200 OK (INVITE) to UA_1. 5. UA_1, when receiving the 200 OK, would normally terminate the early dialog between itself and UA_2. BUT, in this case it can't do it, because it still has an active subscription dialog usage association with UA_2, and the CANCEL sent by the proxy didn't terminate that dialog usage in UA_2 either. Now, the dialog usages still share the same dialog, but from the UA_1 perspective each dialog usage has DIFFERENT route sets and remote targets... Saying that dialog re-usage is only allowed for FULLY ESTABLISHED dialogs would of course solve this, but currentely I think it's legal from a pure SIP perspective. Or? Regards, Christer ------_=_NextPart_001_01C63EB6.D5E8709A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dialog usage: Forking impacts

Hi,

Another scenario related to the dialog = usage issue:

1.      UA_1 = sends an INVITE, which gets forked to UA_2 and UA_3.

2.      UA_2 = establish an early dialog with UA_1 and sends a SUBSCRIBE (or any other = request establishing a new dialog usage) to UA_1, establishing a dialog = usage (subscribe dialog usage in case of SUBSCRIBE).

3.      UA_3 = acceptes the session for the INVITE and sends 200 OK (INVITE)

4.      The = forking proxy sends a CANCEL to UA_2, and forwards the 200 OK (INVITE) = to UA_1.

5.      UA_1, = when receiving the 200 OK, would normally terminate the early dialog = between itself and UA_2. BUT, in this case it can't do it, because it = still has an active subscription dialog usage association with UA_2, and = the CANCEL sent by the proxy didn't terminate that dialog usage in UA_2 = either.

Now, the dialog usages still share the = same dialog, but from the UA_1 perspective each dialog usage has = DIFFERENT route sets and remote targets...

Saying that dialog re-usage is only = allowed for FULLY ESTABLISHED dialogs would of course solve this, but = currentely I think it's legal from a pure SIP perspective. = Or?

Regards,

Christer

------_=_NextPart_001_01C63EB6.D5E8709A-- --===============0856588650== 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 --===============0856588650==-- From sip-bounces@ietf.org Fri Mar 03 08:45:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAZY-0005TE-Gf; Fri, 03 Mar 2006 08:43:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAZW-0005QN-QD for sip@ietf.org; Fri, 03 Mar 2006 08:43:54 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFAZV-0005ro-Av for sip@ietf.org; Fri, 03 Mar 2006 08:43:54 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k23DhmN8013059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Mar 2006 14:43:48 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k23Dhgdb019912; Fri, 3 Mar 2006 14:43:42 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k23DhTJa019909; Fri, 3 Mar 2006 14:43:29 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-fork-loop-fix-00.txt From: Hans Persson To: sip@ietf.org, RjS@nostrum.com, slawrence@pingtel.com, ahawrylyshen@ditechcom.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Fri, 03 Mar 2006 14:43:28 +0100 Message-Id: <1141393408.13702.62.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Fri, 03 Mar 2006 14:43:48 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 interesting to note that a few proxies rebooted during > the scenario, and rejoined in the attack when they restarted (as long > as they maintained registration state across reboots). This points > out that if this attack were launched in the wild, it might require > coordination among all the affected elements to stop it. Yeah, that was lots of fun for all the family. I know I rebooted a few times in that test... ;-) Nits: Page 6, first paragraph: "peform" -> "perform". Section 8: "SIPIT" -> "SIPit". Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 03 09:16:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFB3V-00061v-PU; Fri, 03 Mar 2006 09:14:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFB3U-0005rX-D7 for sip@ietf.org; Fri, 03 Mar 2006 09:14:52 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFB3T-0006fg-FQ for sip@ietf.org; Fri, 03 Mar 2006 09:14:52 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A71504F0052 for ; Fri, 3 Mar 2006 15:14:50 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 15:14:50 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 15:14:50 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Mar 2006 15:14:49 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B2F@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OUTBOUND: Direction of keep-alive requests Thread-Index: AcY+zNUmgWfeSTCqTZC5Nm4N0YlMcg== From: "Christer Holmberg \(JO/LMF\)" To: "IETF SIP List" X-OriginalArrivalTime: 03 Mar 2006 14:14:50.0138 (UTC) FILETIME=[D569F7A0:01C63ECC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Subject: [Sip] OUTBOUND: Direction of keep-alive requests X-BeenThere: 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="===============0139195763==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0139195763== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63ECC.D52A19C2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63ECC.D52A19C2 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, When the different NAT keep-alive mechanisms has been discussed, it seems to be assumed that whatever message is sent, it is originated by the UA (or some other node behind the NAT, on the "private side"). At some point messages originated from the network has also been mentioned, but then the comment has been that many NATs require the the keep-alive messages to be sent from the UA (or some other node behind the NAT). However, in a requst/response based protocols, there WILL be messages sent also in the UA-to-NAT direction; the response messages. So, while the requests from the network would not keep the NAT binding open, the responses would. Of course, whatever proxy that would send these requests would have some kind of B2BUA behavior, and then we get into religious ground again... The advantage, as I see it, would be that in the easiest form no new functionality would be needed in the SIP UAs. They would reply to SIP requests even if they don't understand them, and the binding would be kept open. The disadvantage, of course, is that the UA would not detect when the NAT binding is gone. But, if we would define some extension similar to the session-timer, the UA would (assuming it supports the extension) EXPECT these requests. And, if the requests don't come, the UA could e.g. perform a re-registration. This extension could even be combined with some sending of double CRLFs by the UA, so that the keep-alive requests don't have to be sent that often (still often enough, though). This mechanism of course assmes that the responses are sent to the same IP port/address as where requests would be sent, in order to keep the binding open. I am not saying that this solution would be better or worse than anything else, but at least it is the easiest way to force a client to send a message towards the NAT :) Regards, Christer ------_=_NextPart_001_01C63ECC.D52A19C2 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable OUTBOUND: Direction of keep-alive requests

Hi,

When the different NAT keep-alive = mechanisms has been discussed, it seems to be assumed that whatever = message is sent, it is originated by the UA (or some other node behind = the NAT, on the "private side"). At some point messages = originated from the network has also been mentioned, but then the = comment has been that many NATs require the the keep-alive messages to = be sent from the UA (or some other node behind the NAT).

However, in a requst/response based = protocols, there WILL be messages sent also in the UA-to-NAT direction; = the response messages. So, while the requests from the network would not = keep the NAT binding open, the responses would.

Of course, whatever proxy that would = send these requests would have some kind of B2BUA behavior, and then we = get into religious ground again...

The advantage, as I see it, would be = that in the easiest form no new functionality would be needed in the SIP = UAs. They would reply to SIP requests even if they don't understand = them, and the binding would be kept open.

The disadvantage, of course, is that = the UA would not detect when the NAT binding is gone.

But, if we would define some extension = similar to the session-timer, the UA would (assuming it supports the = extension) EXPECT these requests. And, if the requests don't come, the = UA could e.g. perform a re-registration.

This extension could even be combined = with some sending of double CRLFs by the UA, so that the keep-alive = requests don't have to be sent that often (still often enough, = though).

This mechanism of course assmes that = the responses are sent to the same IP port/address as where requests = would be sent, in order to keep the binding open.

I am not saying that this solution = would be better or worse than anything else, but at least it is the = easiest way to force a client to send a message towards the NAT = :)

Regards,

Christer

------_=_NextPart_001_01C63ECC.D52A19C2-- --===============0139195763== 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 --===============0139195763==-- From sip-bounces@ietf.org Fri Mar 03 09:17:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFB4g-0001AV-62; Fri, 03 Mar 2006 09:16:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFB4e-0001AQ-FT for sip@ietf.org; Fri, 03 Mar 2006 09:16:04 -0500 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFB4e-0006lC-6W for sip@ietf.org; Fri, 03 Mar 2006 09:16:04 -0500 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Mar 2006 09:16:03 -0500 From: "Gary Gan" To: "'Christer Holmberg \(JO/LMF\)'" , "'Dean Willis'" Subject: RE: [Sip] OUTBOUND: How far does a request go? Date: Fri, 3 Mar 2006 09:16:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B11@esealmw113.eemea.ericsson.se> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcY+JnvATsd3ZwgjRZC5R1wJUu87wQAa8xPQAA4lftA= Message-ID: X-OriginalArrivalTime: 03 Mar 2006 14:16:03.0782 (UTC) FILETIME=[014F2660:01C63ECD] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 think the proxy should not forward the keepalive. Before we were worry about the overload of the keepalive to the edge proxy, with this, it would overload more proxies, even the whole SIP network. One way for proxy to proxy NAT keepalive, I think, is to keep track the list of peer proxies that previous visited for a period of time. Each proxy maintains the peer proxy keepalive by itself. - Gary Gan -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: Friday, March 03, 2006 2:21 AM To: Dean Willis Cc: IETF SIP List Subject: RE: [Sip] OUTBOUND: How far does a request go? Hi Dean, > One thing, which I haven't seen being discussed in the "Outbound and > STUN Keep Alive" thread: > > Assuming we DO use a SIP method to keep the NAT binding open, the > questions is whether the request should be terminated by an edge proxy > "on the other side" (from a UA perspective) of the NAT, or if the > request should go all the way to the registrar (scenario shown in > chapter 4.3 of the draft). > > In IMS, the edge proxy would be the P-CSCF, while the S-CSCF would be > the registrar. I am not sure one would like to require the P- CSCF to > forward the NAT keep-alive requests towards the S-CSCF, because it > would only cause unecessary extra traffic in the IMS network. So, for > this reason methods like OPTIONS cannot be used, because OPTIONS WILL > be forwarded by a P-CSCF. So, either the edge proxy must know that it > can terminate certain requests, OR the requests must be addressed to > the edge proxy itself (instead of the registrar). > > And, IF we assume there is no proxy between the UA and the NAT, the > double CRLF "proxy problem" would not be an issue, since no proxy > would be supposed to forward the double CRLF. Of course, there may > still exist other issues with the double CRLF mechanism. A STUN > request would also be terminated by the edge proxy on the other side, > I assume. > > And, if there IS a proxy between the UA and the NAT, I guess that > proxy would have to send the double CRLFs. I don't really see a > difference whether whatever-we-come-up-with has to be implemented in > the UAs, or in the proxy between the UA and the NAT... If we get into the use case of "there is a NAT between the edge proxy and the registrar", then we have a problem if the edge proxy terminates the keepalive. [CHH] The use-case I had in mind is when we have a NAT between a proxy and the edge proxy. The edge proxy would then terminate the keep-alive messages, send by the UAs AND/OR the proxy behind the NAT. Maybe we should use different terms for the proxies we are talking about, depending on where they are located, in order to avoid confusion and missunderstandings... 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 Fri Mar 03 09:46:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBWC-0004uS-4a; Fri, 03 Mar 2006 09:44:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBWA-0004oD-JW for sip@ietf.org; Fri, 03 Mar 2006 09:44:30 -0500 Received: from ptr-64-201-174-137.ptr.terago.ca ([64.201.174.137] helo=cgy01-fw01.citel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFBW9-0007vr-76 for sip@ietf.org; Fri, 03 Mar 2006 09:44:30 -0500 Received: from [10.7.1.3] (helo=not01-mxc01.citel.com) by cgy01-fw01.citel.com with esmtp (Exim 4.43) id 1FFBW8-0003SS-0Q; Fri, 03 Mar 2006 07:44:28 -0700 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 Date: Fri, 3 Mar 2006 14:44:27 -0000 Message-ID: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6CF4@not01-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-worley-sip-dialog-00: Guidelines for Implementing theDialog Event Package in User Agents Thread-Index: AcY7r0heNyiZpr5GQg6JKZ3N+D0FRgDHm00A From: "Michael Procter" To: "Sip" X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Sip] RFC4235 Dialog Event package query X-BeenThere: sip@ietf.org X-Mailman-Version: 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 reading this document, and also Dale Worley's draft containing implementation guidelines (draft-worley-sip-dialog-00). One thing that has come up in the discussions I have had with Dale is the question of what is meant by the mandatory "entity" attribute in the dialog-info element. >From RFC4235 Section 4.1: o entity: This attribute contains a URI that identifies the user whose dialog information is reported in the remainder of the document. This user is referred to as the "observed user". There doesn't appear to be any further discussion of what the entity value should be, but all the examples in the RFC are apparently AORs. (Except for the example in 4.2, which is missing the element = altogether!) It is also unclear what use the element is. I first thought it could be used to distinguish between responses to a forked SUBSCRIBE, but that doesn't make any sense if the entity is the AOR. Maybe the Contact (or better, GRUU) would be a more useful URI to use in those circumstances. Having the entity as the AOR does give the interesting side effect of allowing a GRUU to be mapped back to an AOR, simply by subscribing to the dialog package for the GRUU you are interested in. I remember this was a hot topic a couple of months ago - I don't recall what the result was. A problem with requiring the AOR to be present is that not all UAs know their AOR. There are various devices that are still statically registered and so don't necessarily know their AOR. There are probably other reasons why a UA might not know its AOR aswell. Under these circumstances, I suppose the request-URI might be the best thing to put in the field. So, it seems likely that the intention was that an AOR be used, but there appear to be good and not-so-good reasons to use a contact URI/GRUU instead. I would like to understand what the entity element is for (any use-cases?) and why it is mandatory. Any clarifications to the usage could be added to Dale's draft. Regards, Michael Procter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 03 10:10:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBte-0002rs-TL; Fri, 03 Mar 2006 10:08:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBtd-0002ri-B0 for sip@ietf.org; Fri, 03 Mar 2006 10:08:45 -0500 Received: from smtp02-cell01.bwc.eu.blackberry.com ([216.9.241.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFBtc-0000CA-1r for sip@ietf.org; Fri, 03 Mar 2006 10:08:45 -0500 Received: from engine56-cell01.bwc.produk.on.blackberry (engine56-cell01.bwc.produk.on.blackberry [172.24.140.183]) by smtp02-cell01.bwc.eu.blackberry.com (8.13.1/8.13.1) with SMTP id k1RBf5us005404; Fri, 3 Mar 2006 15:08:36 GMT Message-ID: <887003872-1141398515-cardhu_blackberry.rim.net-21637-@engine56-cell01.bwc.produk.on.blackberry> Content-Transfer-Encoding: quoted-printable Sensitivity: Normal Importance: Normal To: "Christer Holmberg \(JO/LMF\)" To: "IETF SIP List" Subject: Re: [Sip] OUTBOUND: Direction of keep-alive requests From: "David Schwartz" Date: Fri, 3 Mar 2006 15:07:41 +0000 GMT Content-type: text/plain MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.schwartz@kayote.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi=20christer There=20is=20no=20need=20to=20define=20a=20new=20session=20timer=20mechanis= m.=20It=20would=20probably=20be=20easier=20to=20use=20a=20"suppression"=20m= echanism=20similar=20to=20REFER=20implicit=20subscription=20suppression=20b= y=20using=20a=20header=20the=20likes=20of=20"Refer-Sub".=20=20So=20that=20t= he=20UA=20keeps=20behavior=20as=20is=20defined=20curently=20and=20each=20ke= epalive=20ping=20from=20the=20server=20suppresses=20the=20ping=20from=20the= =20UA.=20If=20the=20binding=20is=20lost=20the=20UA=20picks=20up=20where=20i= t=20left=20off. Cheers David -----Original=20Message----- From:=20"Christer=20Holmberg=20\(JO/LMF\)"=20 Date:=20Fri,=203=20Mar=202006=2015:14:49=20 To:"IETF=20SIP=20List"=20 Subject:=20[Sip]=20OUTBOUND:=20Direction=20of=20keep-alive=20requests Hi,=20=0A=20=0AWhen=20the=20different=20NAT=20keep-alive=20mechanisms=20has= =20been=20discussed,=20it=20seems=20to=20be=20assumed=20that=20whatever=20m= essage=20is=20sent,=20it=20is=20originated=20by=20the=20UA=20(or=20some=20o= ther=20node=20behind=20the=20NAT,=20on=20the=20private=20side).=20At=20some= =20point=20messages=20originated=20from=20the=20network=20has=20also=20been= =20mentioned,=20but=20then=20the=20comment=20has=20been=20that=20many=20NAT= s=20require=20the=20the=20keep-alive=20messages=20to=20be=20sent=20from=20t= he=20UA=20(or=20some=20other=20node=20behind=20the=20NAT).=0A=20=0AHowever,= =20in=20a=20requst/response=20based=20protocols,=20there=20WILL=20be=20mess= ages=20sent=20also=20in=20the=20UA-to-NAT=20direction;=20the=20response=20m= essages.=20So,=20while=20the=20requests=20from=20the=20network=20would=20no= t=20keep=20the=20NAT=20binding=20open,=20the=20responses=20would.=0A=20=0AO= f=20course,=20whatever=20proxy=20that=20would=20send=20these=20requests=20w= ould=20have=20some=20kind=20of=20B2BUA=20behavior,=20and=20then=20we=20get= =20into=20religious=20ground=20again...=0A=20=0AThe=20advantage,=20as=20I= =20see=20it,=20would=20be=20that=20in=20the=20easiest=20form=20no=20new=20f= unctionality=20would=20be=20needed=20in=20the=20SIP=20UAs.=20They=20would= =20reply=20to=20SIP=20requests=20even=20if=20they=20don't=20understand=20th= em,=20and=20the=20binding=20would=20be=20kept=20open.=0A=20=0AThe=20disadva= ntage,=20of=20course,=20is=20that=20the=20UA=20would=20not=20detect=20when= =20the=20NAT=20binding=20is=20gone.=20=0A=20=0ABut,=20if=20we=20would=20def= ine=20some=20extension=20similar=20to=20the=20session-timer,=20the=20UA=20w= ould=20(assuming=20it=20supports=20the=20extension)=20EXPECT=20these=20requ= ests.=20And,=20if=20the=20requests=20don't=20come,=20the=20UA=20could=20e.g= .=20perform=20a=20re-registration.=0A=20=0AThis=20extension=20could=20even= =20be=20combined=20with=20some=20sending=20of=20double=20CRLFs=20by=20the= =20UA,=20so=20that=20the=20keep-alive=20requests=20don't=20have=20to=20be= =20sent=20that=20often=20(still=20often=20enough,=20though).=0A=20=0AThis= =20mechanism=20of=20course=20assmes=20that=20the=20responses=20are=20sent= =20to=20the=20same=20IP=20port/address=20as=20where=20requests=20would=20be= =20sent,=20in=20order=20to=20keep=20the=20binding=20open.=0A=20=0AI=20am=20= not=20saying=20that=20this=20solution=20would=20be=20better=20or=20worse=20= than=20anything=20else,=20but=20at=20least=20it=20is=20the=20easiest=20way= =20to=20force=20a=20client=20to=20send=20a=20message=20towards=20the=20NAT= =20:)=0A=20=0ARegards,=20=0A=20=0AChrister=20=0A=20________________________= _______________________ Sip=20mailing=20list=20=20https://www1.ietf.org/mailman/listinfo/sip This=20list=20is=20for=20NEW=20development=20of=20the=20core=20SIP=20Protoc= ol Use=20sip-implementors@cs.columbia.edu=20for=20questions=20on=20current=20s= ip Use=20sipping@ietf.org=20for=20new=20developments=20on=20the=20application= =20of=20sip Sent=20wirelessly=20from=20my=20BlackBerry _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 03 10:18:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFC0p-0006PG-IJ; Fri, 03 Mar 2006 10:16:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFC0n-0006OS-NR for sip@ietf.org; Fri, 03 Mar 2006 10:16:09 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFC0n-0000QD-B9 for sip@ietf.org; Fri, 03 Mar 2006 10:16:09 -0500 Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k23FG25g043157 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 3 Mar 2006 09:16:02 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B1D@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1B1D@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: From: Robert Sparks Date: Fri, 3 Mar 2006 09:16:02 -0600 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (shaman.nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: IETF SIP List , Paul Kyzivat Subject: [Sip] Re: Dialog usage: Forking impacts X-BeenThere: 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="===============0162460971==" Errors-To: sip-bounces@ietf.org --===============0162460971== Content-Type: multipart/alternative; boundary=Apple-Mail-4--116994664 --Apple-Mail-4--116994664 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed inline On Mar 3, 2006, at 5:37 AM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > Another scenario related to the dialog usage issue: > > 1. UA_1 sends an INVITE, which gets forked to UA_2 and UA_3. > > 2. UA_2 establish an early dialog with UA_1 and sends a > SUBSCRIBE (or any other request establishing a new dialog usage) to > UA_1, establishing a dialog usage (subscribe dialog usage in case > of SUBSCRIBE). > > 3. UA_3 acceptes the session for the INVITE and sends 200 OK > (INVITE) > > 4. The forking proxy sends a CANCEL to UA_2, and forwards the > 200 OK (INVITE) to UA_1. > > 5. UA_1, when receiving the 200 OK, would normally terminate > the early dialog between itself and UA_2. BUT, in this case it > can't do it, because it still has an active subscription dialog > usage association with UA_2, and the CANCEL sent by the proxy > didn't terminate that dialog usage in UA_2 either. > > Now, the dialog usages still share the same dialog, but from the > UA_1 perspective each dialog usage has DIFFERENT route sets and > remote targets... UA_1 and UA_2 have a different dialog than UA_1 and UA_3. The to-tags returned by 2 and 3 will be different. It is normal that the route sets and remote targets for these different dialogs will be different. the 1-2 dialog has two usages before the cancel (and early session usage, and a subscribe). After the cancel it has one usage (the subscription). The 1-3 dialog has only one usage in its existence. > Saying that dialog re-usage is only allowed for FULLY ESTABLISHED > dialogs would of course solve this, but currentely I think it's > legal from a pure SIP perspective. Or? I don't see anything special here about early vs confirmed early- session usages wrt dialog reuse. But I will point out that I'd be _really_ surprised if more than a trivial number of implementations did the right thing with the subscription above. > Regards, > > Christer > --Apple-Mail-4--116994664 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
inline


On Mar 3, = 2006, at 5:37 AM, Christer Holmberg ((JO/LMF)) wrote:

=

Hi,

Another scenario related to the dialog usage = issue:

1.=A0=A0=A0=A0=A0 = UA_1 sends an INVITE, which gets forked to UA_2 and UA_3. =

2.=A0=A0=A0=A0=A0 UA_2 establish = an early dialog with UA_1 and sends a SUBSCRIBE (or any other request = establishing a new dialog usage) to UA_1, establishing a dialog usage = (subscribe dialog usage in case of SUBSCRIBE).

3.=A0=A0=A0=A0=A0 UA_3 acceptes the session = for the INVITE and sends 200 OK (INVITE)

4.=A0=A0=A0=A0=A0 The forking proxy sends a CANCEL to = UA_2, and forwards the 200 OK (INVITE) to UA_1.

5.=A0=A0=A0=A0=A0 UA_1, when receiving the 200 = OK, would normally terminate the early dialog between itself and UA_2. = BUT, in this case it can't do it, because it still has an active = subscription dialog usage association with UA_2, and the CANCEL sent by = the proxy didn't terminate that dialog usage in UA_2 = either.

Now, the dialog = usages still share the same dialog, but from the UA_1 perspective each = dialog usage has DIFFERENT route sets and remote = targets...

UA_1 and UA_2 have a different = dialog=A0than=A0 UA_1 and UA_3.=A0
The to-tags returned by 2 = and 3 will be different. It is normal that the
route sets and = remote targets for these different dialogs will be = different.

the 1-2 dialog has two usages before = the cancel (and early session usage, and a subscribe). After the = cancel
it has one usage (the subscription).=A0

The 1-3 dialog has only one = usage in its existence.


Saying that dialog = re-usage is only allowed for FULLY ESTABLISHED dialogs would of course = solve this, but currentely I think it's legal from a pure SIP = perspective. Or?

I don't see anything special = here about early vs confirmed early-session usages wrt dialog = reuse.

But I = will point out that I'd be _really_ surprised if more than a trivial = number of implementations
did the right thing with the = subscription above.

Regards,

Christer

=

= --Apple-Mail-4--116994664-- --===============0162460971== 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 --===============0162460971==-- From sip-bounces@ietf.org Fri Mar 03 10:26:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFC8z-0005IW-IQ; Fri, 03 Mar 2006 10:24:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFC8y-0005IR-DT for sip@ietf.org; Fri, 03 Mar 2006 10:24:36 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFC8x-0000rv-61 for sip@ietf.org; Fri, 03 Mar 2006 10:24:36 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id CD3D86C017; Fri, 3 Mar 2006 10:24:34 -0500 (EST) Subject: RE: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 From: Scott Lawrence To: Samir Srivastava In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60AABE56C@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60AABE56C@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Fri, 03 Mar 2006 10:24:34 -0500 Message-Id: <1141399474.2954.42.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Thu, 2006-03-02 at 13:07 -0600, Samir Srivastava wrote: > IMHO, Please add proxy pruning too. > > If It need to truncate via/RR also, can we show in the body that > response is truncated one ?? I'm not sure that I understand your question. If what you are asking is if there is something in the response that tells the recipient it is not the complete set of headers, then the answer is that at present there is not. If you are asking whether or not it is ok to also remove some of the Via and RR headers, then I would say that doing so would dramatically reduce the utility of including anything; in fact, it might be worse than returning nothing at all. Or were you asking for something else? -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com Consulting Engineer - Pingtel Corp. http://www.pingtel.com/ sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 03 10:27:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFC9z-0006T3-8v; Fri, 03 Mar 2006 10:25:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFC9y-0006S0-1l for sip@ietf.org; Fri, 03 Mar 2006 10:25:38 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFC9x-0000uu-Pu for sip@ietf.org; Fri, 03 Mar 2006 10:25:38 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 03 Mar 2006 10:25:37 -0500 X-IronPort-AV: i="4.02,163,1139202000"; d="scan'208"; a="83453222:sNHT33490128" 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 k23FPbWc015960; Fri, 3 Mar 2006 10:25:37 -0500 (EST) 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.211); Fri, 3 Mar 2006 10:25:36 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Mar 2006 10:25:36 -0500 Message-ID: <44085FF0.3000200@cisco.com> Date: Fri, 03 Mar 2006 10:25:36 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" References: <5EB80D22825EEE42872083AD5BFFB5945D1B1D@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B1D@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2006 15:25:36.0611 (UTC) FILETIME=[B8825330:01C63ED6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: IETF SIP List Subject: [Sip] Re: Dialog usage: Forking impacts X-BeenThere: sip@ietf.org X-Mailman-Version: 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, > > Another scenario related to the dialog usage issue: > > 1. UA_1 sends an INVITE, which gets forked to UA_2 and UA_3. > > 2. UA_2 establish an early dialog with UA_1 and sends a SUBSCRIBE > (or any other request establishing a new dialog usage) to UA_1, > establishing a dialog usage (subscribe dialog usage in case of SUBSCRIBE). > > 3. UA_3 acceptes the session for the INVITE and sends 200 OK (INVITE) > > 4. The forking proxy sends a CANCEL to UA_2, and forwards the 200 > OK (INVITE) to UA_1. > > 5. UA_1, when receiving the 200 OK, would normally terminate the > early dialog between itself and UA_2. BUT, in this case it can't do it, > because it still has an active subscription dialog usage association > with UA_2, and the CANCEL sent by the proxy didn't terminate that dialog > usage in UA_2 either. This does point up some issues with language in the RFCs. I doubt there really is any such thing as an "early dialog". In reality there is only one kind of dialog, but there is an "early invite dialog usage". > Now, the dialog usages still share the same dialog, but from the UA_1 > perspective each dialog usage has DIFFERENT route sets and remote targets... Don't think I agree. Following step 3, or maybe sooner, UA1 knows there are two dialogs, because it has received responses with different to-tags. The early invite dialog usage with UA2 and the subscribe from UA2 share one dialog, and the invite dialog usage with UA3 uses the other dialog. There isn't anything new here due to sharing. UA2 and UA3 could have both established early invite dialog usages. UA1 has to deal with two dialogs in that case as well. The key thing in all this is that the lifetime of dialogs is not explicitly managed. Rather it is reference counted based on the usages that share it. > Saying that dialog re-usage is only allowed for FULLY ESTABLISHED > dialogs would of course solve this, but currentely I think it's legal > from a pure SIP perspective. Or? This is one of the reasons why I think it is a bad idea to start putting restrictions on the use of shared dialogs. As things stand, the whole ediface does tie together using just a few basic principles. If you support those principles, then all the different possible combinations of usages will work. If you impose restrictions on the kinds of usages that are allowed, you encourage implementations that implement all sorts of special case logic. Figuring out what special case logic is sufficient is harder than implementing the general case. Paul > 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 Mar 03 10:40:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFCMi-0004uh-FM; Fri, 03 Mar 2006 10:38:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFCMg-0004oP-HB for sip@ietf.org; Fri, 03 Mar 2006 10:38:46 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFCMf-0001Tk-2D for sip@ietf.org; Fri, 03 Mar 2006 10:38:46 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k23Fcf1d019023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Mar 2006 16:38:41 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k23FcaGC023010; Fri, 3 Mar 2006 16:38:36 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k23FcMGj023005; Fri, 3 Mar 2006 16:38:22 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: RE: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 From: Hans Persson To: Scott Lawrence In-Reply-To: <1141399474.2954.42.camel@sukothai.pingtel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60AABE56C@zrc2hxm2.corp.nortel.com> <1141399474.2954.42.camel@sukothai.pingtel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Fri, 03 Mar 2006 16:38:21 +0100 Message-Id: <1141400301.22882.4.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Fri, 03 Mar 2006 16:38:41 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 fre 2006-03-03 klockan 10:24 -0500 skrev Scott Lawrence: > If what you are asking is if there is something in the response that > tells the recipient it is not the complete set of headers, then the > answer is that at present there is not. > > If you are asking whether or not it is ok to also remove some of the Via > and RR headers, then I would say that doing so would dramatically reduce > the utility of including anything; in fact, it might be worse than > returning nothing at all. I interpreted his question as asking whether it would be possible for the recipient of the 483 to tell whether the returned set of headers was complete or not. If Via/Route headers have been pruned, knowing this would be much more important than if just User-Agent/Subject/etc has been removed. However, I still see a use for something like SIP/2.0 483 Too many hops From: Sip Send ;tag=612f37e7 To: sip:9999@interop.pingtel.com Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 Cseq: 1 INVITE Via: SIP/2.0/TCP 10.1.1.20:40221 ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f Content-Type: message/sipfrag Content-Length: whatever Date: Fri, 14 Oct 2005 15:27:47 GMT INVITE sip:InfiniteLoop@interop.pingtel.com SIP/2.0 Record-Route: Via: SIP/2.0/TCP 192.0.2.162 ;branch=z9hG4bK-42e47bba67559bd9a3da1934a70bbc37 Via: SIP/2.0/TCP 192.0.2.162:5080 ;branch=z9hG4bK-50d909f1209f7a820de85c7831846330 Via: SIP/2.0/TCP 192.0.2.162 ;branch=z9hG4bK-994f162bc179fb75093166fabbfd13c7 Via: SIP/2.0/TCP 192.0.2.162:5080 ;branch=z9hG4bK-708842ad6ea22f8fa6e39c503d3d803e X-Comment: Only top four Via headers preserved. if the message size needs to be kept down. I'm not saying that X-Comment is necessarily a kosher way to get that information across, but you get the idea. If I want to figure out what happened to get where we ended up, I need to send the same request again, but with a lower Max- Forwards. Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 03 14:08:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFbX-0005Q5-Gd; Fri, 03 Mar 2006 14:06:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFbV-0005Jm-6w for sip@ietf.org; Fri, 03 Mar 2006 14:06:17 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFFbT-0000uZ-Tt for sip@ietf.org; Fri, 03 Mar 2006 14:06:17 -0500 Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k23J6CK2054136 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 3 Mar 2006 13:06:15 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <5BF981E0-D49E-4322-B1E4-0C442AD0CE6A@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Robert Sparks Date: Fri, 3 Mar 2006 13:06:11 -0600 X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (shaman.nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Sip] nit-future refreshed but not changed X-BeenThere: sip@ietf.org X-Mailman-Version: 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 submitted an update to the nit-future draft. There have been no substantive changes. The references were touched to follow what's progressed. This is a no-op update to get the data back into the repository (I had let the previous version expire). 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 Fri Mar 03 15:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGU4-0003n6-79; Fri, 03 Mar 2006 15:02:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGU2-0003it-Ny; Fri, 03 Mar 2006 15:02:38 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFGU1-0002k9-Fo; Fri, 03 Mar 2006 15:02:38 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id DC84636C48D; Fri, 3 Mar 2006 12:02:36 -0800 (PST) Received: from [10.1.28.3] (unknown [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 6AC7336C488; Fri, 3 Mar 2006 12:02:34 -0800 (PST) Message-ID: <4408A0D9.7000204@acm.org> Date: Fri, 03 Mar 2006 12:02:33 -0800 From: Marc Petit-Huguenin User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: henry@pulver.com Subject: Running code [was Re: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'Cullen Jennings' , sip@ietf.org, 'sipping' , 'Jon Peterson' , 'Allison Mankin' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henry Sinnreich wrote: >>In the end, the bulk of the work is done by volunteers that read drafts, >>provide ideas and comments, and write the drafts - it the people that >>count. > > > I could not agree more, except to add the highest value is added by people > who also write code before submitting an I-D written on a word processor. > > Mybe most of the issues discussed here could be solved by imposing the good > old IETF rule "we believe in running code". > > Writing code first would certainly reduce the avalanche of word processor > output that gave us the problems that Dean mentioned. > > Actually, how much value is there in an I-D that is not backed up by running > code? Admittedly there are some framework documents, requirements, etc., but > they are the exception to the rule "we believe in running code". > > Thanks, Henry > > As a developer, I completely agree to what you are saying here, so here is an idea: What about a standardized section in future I-D/RFC that list the running code that implement this document - like a "Running Code Considerations", after the "IANA Considerations" and "Security Considerations" sections. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.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 Mar 03 15:22:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGlU-0003sd-3Q; Fri, 03 Mar 2006 15:20:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGlS-0003sY-O8 for sip@ietf.org; Fri, 03 Mar 2006 15:20:38 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFGlR-0003L8-Da for sip@ietf.org; Fri, 03 Mar 2006 15:20:38 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k23KKF129291; Fri, 3 Mar 2006 15:20:16 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 Date: Fri, 3 Mar 2006 14:20:02 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AB28879@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 Thread-Index: AcY+2JqEUcD91x4mTLKxEBxy8TIXUQAIr4kg From: "Samir Srivastava" To: "Hans Persson" , "Scott Lawrence" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 Hans described my concerns clearly.=20 Additionally, In this case we are more concerned about the via. RR is second important header. If only RR is pruned, it should indicate "4 RR are preserved " if via is also pruned, It should state "RR is pruned, and only top 4 via are preserved" . As this is debugging utility, If my proxies are doing record routing, and If I see mismatch in RR and via headers in response, I might suspect there is something wrong in record routing logic too.=20 Thx Samir -----Original Message----- From: Hans Persson [mailto:hasse@ingate.com]=20 Sent: Friday, March 03, 2006 7:38 AM To: Scott Lawrence Cc: Srivastava, Samir [SC100:8826:EXCH]; sip@ietf.org Subject: RE: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 fre 2006-03-03 klockan 10:24 -0500 skrev Scott Lawrence: > If what you are asking is if there is something in the response that=20 > tells the recipient it is not the complete set of headers, then the=20 > answer is that at present there is not. >=20 > If you are asking whether or not it is ok to also remove some of the=20 > Via and RR headers, then I would say that doing so would dramatically=20 > reduce the utility of including anything; in fact, it might be worse=20 > than returning nothing at all. I interpreted his question as asking whether it would be possible for the recipient of the 483 to tell whether the returned set of headers was complete or not. If Via/Route headers have been pruned, knowing this would be much more important than if just User-Agent/Subject/etc has been removed. However, I still see a use for something like=20 SIP/2.0 483 Too many hops From: Sip Send ;tag=3D612f37e7 To: sip:9999@interop.pingtel.com Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 Cseq: 1 INVITE Via: SIP/2.0/TCP 10.1.1.20:40221 ;branch=3Dz9hG4bK-931ea14405e9da8c95cf4ed60a71f59f Content-Type: message/sipfrag Content-Length: whatever Date: Fri, 14 Oct 2005 15:27:47 GMT INVITE sip:InfiniteLoop@interop.pingtel.com SIP/2.0 Record-Route: Via: SIP/2.0/TCP 192.0.2.162 ;branch=3Dz9hG4bK-42e47bba67559bd9a3da1934a70bbc37 Via: SIP/2.0/TCP 192.0.2.162:5080 ;branch=3Dz9hG4bK-50d909f1209f7a820de85c7831846330 Via: SIP/2.0/TCP 192.0.2.162 ;branch=3Dz9hG4bK-994f162bc179fb75093166fabbfd13c7 Via: SIP/2.0/TCP 192.0.2.162:5080 ;branch=3Dz9hG4bK-708842ad6ea22f8fa6e39c503d3d803e X-Comment: Only top four Via headers preserved. if the message size needs to be kept down. I'm not saying that X-Comment is necessarily a kosher way to get that information across, but you get the idea. If I want to figure out what happened to get where we ended up, I need to send the same request again, but with a lower Max- Forwards. Hans --=20 Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 03 16:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHvW-0000p1-5a; Fri, 03 Mar 2006 16:35:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHvU-0000ok-FE for sip@ietf.org; Fri, 03 Mar 2006 16:35:04 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFHvR-0005Qn-RI for sip@ietf.org; Fri, 03 Mar 2006 16:35:04 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 857A31403F1; Fri, 3 Mar 2006 23:34:59 +0200 (EET) Received: from rautu (unknown [202.73.194.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 62FDD1403E5; Fri, 3 Mar 2006 23:34:53 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 7C024F027C; Fri, 3 Mar 2006 23:34:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17416.46713.943116.346797@rautu.tutpro.com> Date: Fri, 3 Mar 2006 23:34:49 +0200 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: [Sip] OUTBOUND: Direction of keep-alive requests In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B2F@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1B2F@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Christer Holmberg (JO/LMF) writes: > At some point messages originated from the network has also been mentioned, > but then the comment has been that many NATs require the the keep-alive > messages to be sent from the UA (or some other node behind the NAT). there may indeed be such NATs, but looks like none of users of my proxy have managed to buy one, because nobody has complained. so are you sure the problem is worth solving? -- 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 Fri Mar 03 17:00:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFIIX-0005jp-1D; Fri, 03 Mar 2006 16:58:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHld-0000xh-6j for sip@ietf.org; Fri, 03 Mar 2006 16:24:53 -0500 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 1FFHJJ-00061X-Re for sip@ietf.org; Fri, 03 Mar 2006 15:55:39 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 03 Mar 2006 12:55:28 -0800 X-IronPort-AV: i="4.02,163,1139212800"; d="scan'208,217"; a="311694133:sNHT26019752778" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k23KtRGv002444; Fri, 3 Mar 2006 12:55:27 -0800 (PST) Received: from 10.21.124.95 ([10.21.124.95]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 3 Mar 2006 20:55:27 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 03 Mar 2006 12:55:25 -0800 Subject: Re: [Sip] sip-identity-06's compressed archive file From: Cullen Jennings To: , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] sip-identity-06's compressed archive file Thread-Index: AcY/BMtOCbaRXKr4EdqNDQARJEEJ/A== In-Reply-To: <200602062001.k16K1lnH023425@GATE01.NEXLINK.CH> Mime-version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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="===============1932197843==" Errors-To: sip-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1932197843== Content-type: multipart/alternative; boundary="B_3224235325_1033327" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3224235325_1033327 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 2/6/06 12:01 PM, "Jo=EBl Repiquet" wrote: > However, would it be possible to get the corrected base-64 encoded block = now? This seems to work for me. (PS thanks for the other catch with the name ) --B_3224235325_1033327 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Sip] sip-identity-06's compressed archive file On 2/= 6/06 12:01 PM, "Joël Repiquet" <joel.repiquet@tech-invite.= com> wrote:

However, would it be possible to get the corrected base= -64 encoded block now?

This seems to work for me.

(PS thanks for the other catch with the name )
 --B_3224235325_1033327-- --===============1932197843== 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 --===============1932197843==-- From sip-bounces@ietf.org Fri Mar 03 17:43:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFIy2-0004gM-UQ; Fri, 03 Mar 2006 17:41:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFIy1-0004gH-HW for sip@ietf.org; Fri, 03 Mar 2006 17:41:45 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFIy0-0000h0-7y for sip@ietf.org; Fri, 03 Mar 2006 17:41:45 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 2E0336C017; Fri, 3 Mar 2006 17:41:43 -0500 (EST) Subject: RE: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 From: Scott Lawrence To: Hans Persson In-Reply-To: <1141400301.22882.4.camel@eeek.ingate.se> References: <62B9B0847CC47543B6B3B5E26BD268E60AABE56C@zrc2hxm2.corp.nortel.com> <1141399474.2954.42.camel@sukothai.pingtel.com> <1141400301.22882.4.camel@eeek.ingate.se> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Fri, 03 Mar 2006 17:41:42 -0500 Message-Id: <1141425703.2954.63.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Fri, 2006-03-03 at 16:38 +0100, Hans Persson wrote: > fre 2006-03-03 klockan 10:24 -0500 skrev Scott Lawrence: > > > If what you are asking is if there is something in the response that > > tells the recipient it is not the complete set of headers, then the > > answer is that at present there is not. > > > > If you are asking whether or not it is ok to also remove some of the Via > > and RR headers, then I would say that doing so would dramatically reduce > > the utility of including anything; in fact, it might be worse than > > returning nothing at all. > > I interpreted his question as asking whether it would be possible for > the recipient of the 483 to tell whether the returned set of headers was > complete or not. If Via/Route headers have been pruned, knowing this > would be much more important than if just User-Agent/Subject/etc has > been removed. > > However, I still see a use for something like > > SIP/2.0 483 Too many hops > From: Sip Send ;tag=612f37e7 > To: sip:9999@interop.pingtel.com > Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 > Cseq: 1 INVITE > Via: SIP/2.0/TCP 10.1.1.20:40221 > ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f > Content-Type: message/sipfrag > Content-Length: whatever > Date: Fri, 14 Oct 2005 15:27:47 GMT > > INVITE sip:InfiniteLoop@interop.pingtel.com SIP/2.0 > Record-Route: ;lr;a;t=612f37e7;s=96e09e8e8c93a8c60bf460029847f4b1> > Via: SIP/2.0/TCP 192.0.2.162 > ;branch=z9hG4bK-42e47bba67559bd9a3da1934a70bbc37 > Via: SIP/2.0/TCP 192.0.2.162:5080 > ;branch=z9hG4bK-50d909f1209f7a820de85c7831846330 > Via: SIP/2.0/TCP 192.0.2.162 > ;branch=z9hG4bK-994f162bc179fb75093166fabbfd13c7 > Via: SIP/2.0/TCP 192.0.2.162:5080 > ;branch=z9hG4bK-708842ad6ea22f8fa6e39c503d3d803e > X-Comment: Only top four Via headers preserved. > > if the message size needs to be kept down. I'm not saying that X-Comment > is necessarily a kosher way to get that information across, but you get > the idea. If I want to figure out what happened to get where we ended > up, I need to send the same request again, but with a lower Max- > Forwards. Yes, that's possible. I wouldn't want to embed the indication in the body itself; I think that introduces to much ambiguity (did someone on the path send that X-Comment?). We could define a parameter for the Content-Type... Content-Type: message/sipfrag;truncated It is probably important to specify that if you're going to remove any Vias, Routes, or Record-Routes, that you always remove those that are furthest from the system that is returning the error (closest to the originator of the message). -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com Consulting Engineer - Pingtel Corp. http://www.pingtel.com/ sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 03 18:36:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFJnN-0002Vh-Oo; Fri, 03 Mar 2006 18:34:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFJnL-0002Rj-CK; Fri, 03 Mar 2006 18:34:47 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFJnK-0002vr-1z; Fri, 03 Mar 2006 18:34:47 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k23NYuYJ020151 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 3 Mar 2006 17:34:57 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Running code [was Re: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering] Date: Fri, 3 Mar 2006 17:34:37 -0600 To: henry@pulver.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'Cullen Jennings' , 'Marc Petit-Huguenin' , 'Jon Peterson' , 'Allison Mankin' , sip@ietf.org, 'sipping' X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 3, 2006, at 4:21 PM, Henry Sinnreich wrote: > Marc, > >> What about a standardized section in future I-D/RFC that list the >> running >> code that implement this document - like a "Running Code >> Considerations", >> after the "IANA Considerations" and "Security Considerations" >> sections. > > This is an excellent proposal and I would also add: > > Documents that are only proposals or concepts, but are not backed > up by > running code can be very well exchaged as e-mails on the various > lists. > In this way, WG I-D overload would disappear and Dean's problem > will be > solved. > > If there is no running code, discussions on e-mail is just fine. > > Thanks, Henry > > Lovely idea, but needs to be part of the IETF process, not the SIP process. The New Track working group, perhaps? -- 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 Mar 03 18:52:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFK26-0006cE-Ts; Fri, 03 Mar 2006 18:50:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFK25-0006bw-73; Fri, 03 Mar 2006 18:50:01 -0500 Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFK24-00039P-UK; Fri, 03 Mar 2006 18:50:01 -0500 Received: from [64.241.37.140] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 13057147; Fri, 03 Mar 2006 16:45:54 -0700 Message-Id: <7.0.1.0.0.20060303184413.034e6ee0@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 03 Mar 2006 18:49:57 -0500 To: sip@ietf.org,'sipping' From: "Joel M. Halpern" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.9 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [Sip] Re: Running code X-BeenThere: sip@ietf.org X-Mailman-Version: 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, I couldn't let this go without comment. I have trimmed the CC so the leadership won't receive 3 copies.] For SIP, maybe the problem space is in a state where that is practical (although I doubt it.) For many other working groups, it would be really strange to require running code before accepting a draft for discussion. For example, in ForCES we needed to agree on what the structure of the ForCES protocol needed to be. Requiring people to implement ideas that we wanted to discuss would have made it very hard to have clear discussion. Particularly since we had not agreed on the underlying transport, so it would have been easy to confuse transport properties with application properties. In general, with new work it is pretty hard to require implementation of the early stage ideas. It can sometimes even be counter-productive. Efforts to provide early implementations of alternative management structures seemed to cause those emplementors to become wedded to their particularl approach. I definitely like implementation. The routing area is in fact increasing the emphasis on implementation before standardization. But implementation before I-D seems a mistake. We usually ask folks to write up an I-D on anything they want discussed. And in most working groups, if the topic is on charter and the approach looks sane, the document is often made a WG document to create a clear trackable state for the work. Yours, Joel M. Halpern At 06:34 PM 3/3/2006, Dean Willis wrote: >>Documents that are only proposals or concepts, but are not backed >>up by >>running code can be very well exchaged as e-mails on the various >>lists. >>In this way, WG I-D overload would disappear and Dean's problem >>will be >>solved. >> >>If there is no running code, discussions on e-mail is just fine. >> >>Thanks, Henry > >Lovely idea, but needs to be part of the IETF process, not the SIP >process. The New Track working group, perhaps? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 03 19:30:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFKdQ-0007XH-I3; Fri, 03 Mar 2006 19:28:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFKdP-0007Wi-B1; Fri, 03 Mar 2006 19:28:35 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFKdN-0000BL-Vo; Fri, 03 Mar 2006 19:28:35 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 82F7036C48B; Fri, 3 Mar 2006 16:28:33 -0800 (PST) Received: from [10.1.28.3] (unknown [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 354A336C483; Fri, 3 Mar 2006 16:28:32 -0800 (PST) Message-ID: <4408DF2F.7020204@acm.org> Date: Fri, 03 Mar 2006 16:28:31 -0800 From: Marc Petit-Huguenin User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Sip] Re: Running code References: <7.0.1.0.0.20060303184413.034e6ee0@stevecrocker.com> In-Reply-To: <7.0.1.0.0.20060303184413.034e6ee0@stevecrocker.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org, 'sipping' X-BeenThere: sip@ietf.org X-Mailman-Version: 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 way I see it, the I-D can start with an empty Running Code section, like it is often the case with the IANA or Security section. As the draft evolves, it can keep track of the various implementation of the I-D in this section. This could be also a good indicator of the interest in this work. Joel M. Halpern wrote: > [Sorry, I couldn't let this go without comment. I have trimmed the CC > so the leadership won't receive 3 copies.] > > For SIP, maybe the problem space is in a state where that is practical > (although I doubt it.) > > For many other working groups, it would be really strange to require > running code before accepting a draft for discussion. For example, in > ForCES we needed to agree on what the structure of the ForCES protocol > needed to be. Requiring people to implement ideas that we wanted to > discuss would have made it very hard to have clear discussion. > Particularly since we had not agreed on the underlying transport, so it > would have been easy to confuse transport properties with application > properties. > > In general, with new work it is pretty hard to require implementation of > the early stage ideas. It can sometimes even be counter-productive. > Efforts to provide early implementations of alternative management > structures seemed to cause those emplementors to become wedded to their > particularl approach. > > I definitely like implementation. The routing area is in fact > increasing the emphasis on implementation before standardization. But > implementation before I-D seems a mistake. We usually ask folks to > write up an I-D on anything they want discussed. And in most working > groups, if the topic is on charter and the approach looks sane, the > document is often made a WG document to create a clear trackable state > for the work. > > Yours, > Joel M. Halpern > > At 06:34 PM 3/3/2006, Dean Willis wrote: > >>> Documents that are only proposals or concepts, but are not backed >>> up by >>> running code can be very well exchaged as e-mails on the various >>> lists. >>> In this way, WG I-D overload would disappear and Dean's problem >>> will be >>> solved. >>> >>> If there is no running code, discussions on e-mail is just fine. >>> >>> Thanks, Henry >> >> >> Lovely idea, but needs to be part of the IETF process, not the SIP >> process. The New Track working group, perhaps? > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.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 Mar 03 19:52:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFKyf-0002hh-6a; Fri, 03 Mar 2006 19:50:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFKyd-0002dR-RZ for sip@ietf.org; Fri, 03 Mar 2006 19:50:31 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFKyb-0002Gb-Jd for sip@ietf.org; Fri, 03 Mar 2006 19:50:31 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 03 Mar 2006 16:50:29 -0800 Received: from dwingwxp ([10.32.240.197]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k240oS7T011171; Fri, 3 Mar 2006 16:50:28 -0800 (PST) From: "Dan Wing" To: "'Thejeswara Reddy'" , "'sip ietf'" Subject: RE: [Sip] sip over T/TCP Date: Fri, 3 Mar 2006 16:50:28 -0800 Message-ID: <0d3b01c63f25$a224d320$c5f0200a@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.2180 Thread-Index: AcY+JWZwF98sqtmLSzqoBH8JvABvEABADFVQ In-reply-to: <20060302181544.83635.qmail@web8613.mail.in.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 See http://www.postel.org/pipermail/end2end-interest/2005-December/005552.html -d > hai, > can SIP used over T/TCP ? > >>>>>>>as T/TCP has advatageous over TCP and UDP > is there any limitations ? > > thanks > theja > > > ________________________________ > > Jiyo cricket on Yahoo! India cricket > yahoo.com/cricket/> > Yahoo! Messenger Mobile > Stay in touch with your buddies all the time. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 04 02:59:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFRdz-00013G-G5; Sat, 04 Mar 2006 02:57:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFRdw-000138-Id; Sat, 04 Mar 2006 02:57:36 -0500 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFRdv-0006vU-AP; Sat, 04 Mar 2006 02:57:36 -0500 Received: from moe.nextone.local ([192.168.15.39]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Mar 2006 02:57:34 -0500 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: Running code Date: Sat, 4 Mar 2006 02:57:33 -0500 Message-ID: <8812D8156467224C9E9739E513037EF12A1791@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: Running code Thread-Index: AcY/HX7i8O7mh5xzSTyxFmADEiQm5gAQiaMg From: "Bob Natale" To: "Joel M. Halpern" X-OriginalArrivalTime: 04 Mar 2006 07:57:34.0661 (UTC) FILETIME=[4C080750:01C63F61] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org, sipping X-BeenThere: sip@ietf.org X-Mailman-Version: 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 agree with Joel's caution here. After all (speculating on intent a bit, I admit): it's "rough consensus and running code", not "running code and rough consensus" nor (in Joel's counter-productive reference) "rough consensus about running code". I've always interpreted the maxim as "rough consensus and [then] running code" or "rough consensus supported by running code". Either way, we get to the "rough consensus" first, at least logically. Cheers, BobN -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 Sent: Friday, March 03, 2006 6:50 PM To: sip@ietf.org; 'sipping' Subject: [Sip] Re: Running code=20 [Sorry, I couldn't let this go without comment. I have trimmed the CC so the leadership won't receive 3 copies.] For SIP, maybe the problem space is in a state where that is practical (although I doubt it.) For many other working groups, it would be really strange to require running code before accepting a draft for discussion. For example, in ForCES we needed to agree on what the structure of the ForCES protocol needed to be. Requiring people to implement ideas that we wanted to discuss would have made it very hard to have clear discussion. Particularly since we had not agreed on the underlying transport, so it would have been easy to confuse transport properties with application properties. In general, with new work it is pretty hard to require implementation of the early stage ideas. It can sometimes even be counter-productive. Efforts to provide early implementations of alternative management structures seemed to cause those emplementors to become wedded to their particularl approach. I definitely like implementation. The routing area is in fact increasing the emphasis on implementation before standardization. But implementation before I-D seems a mistake. We usually ask folks to write up an I-D on anything they want discussed. And in most working groups, if the topic is on charter and the approach looks sane, the document is often made a WG document to create a clear trackable state for the work. Yours, Joel M. Halpern At 06:34 PM 3/3/2006, Dean Willis wrote: >>Documents that are only proposals or concepts, but are not backed up=20 >>by running code can be very well exchaged as e-mails on the various=20 >>lists. >>In this way, WG I-D overload would disappear and Dean's problem will=20 >>be solved. >> >>If there is no running code, discussions on e-mail is just fine. >> >>Thanks, Henry > >Lovely idea, but needs to be part of the IETF process, not the SIP=20 >process. The New Track working group, perhaps? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 04 10:05:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFYIZ-0002MD-Vv; Sat, 04 Mar 2006 10:03:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFYIY-0002Gd-0l; Sat, 04 Mar 2006 10:03:58 -0500 Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFYIW-0002cy-I0; Sat, 04 Mar 2006 10:03:57 -0500 Received: from user-2ivf924.dsl.mindspring.com ([165.247.164.68] helo=JMHLap3.stevecrocker.com) by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FFYIT-0006r8-00; Sat, 04 Mar 2006 10:03:54 -0500 Message-Id: <7.0.1.0.0.20060304094900.0328d910@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 04 Mar 2006 10:03:50 -0500 To: From: "Joel M. Halpern" Subject: RE: [Sipping] Re: [Sip] Re: Running code In-Reply-To: References: <4408DF2F.7020204@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: sip@ietf.org, 'Marc Petit-Huguenin' , 'sipping' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Let's try to separate the pieces. Having implementations as early as possible is clearly a good idea. It is sometimes practical to have an implementation along with the first I-D on a topic. When it is practical, it is often helpful. There are many cases where it is not practical. There are cases where it is even counter productive. (As far as I can tell, much of the argument over the proposals in the OSPF-MANET extensions is because folks are wedded to the proposals they have implemented, and they have lovely simulations using their code to show why their answer is better.) Part of my concern here is that for all that we need "bits on the wire" to get things to work, it is often counter-productive to argue about bits-on-the wire before one agrees on how a protocol ought to behave. Having an I-D to discuss that describes a particular approach is MUCH better than just having an email discussion. In quite a few working groups I work in, the response to an interesting idea is "give us a draft". That allows the working group to understand the idea at a suitable level of detail. It would be really bad if that were only permitted after the person suggesting the idea had built an implementation. It is also the case that implementation can be counter-productive. I can recall a case where a participant in a working group wanted the standard to essentially require an all-paths graph traversal. Several of us told him this was a bad idea. He went and implemented and measured it. He said , roughly ~see, it works and it isn't too expensive.~ It was not too expensive in his tests, with other limitations, etc. However, there was no question that it was a bad idea. Implementation is a good tool. It is not always the right answer. I had an implementation of XCAP. I could not and would not have built my implementation if the I-D had not existed. There was no way I could have taken the time of product engineers to build something that was not even an I-D, much less an I-D with some traction in the working group. By building it, we learned some things that helped shape the work. I am not arguing that implementation is not a good idea. It is a good idea. But requiring implementation before the first I-D is difficult and often counter-productive. Let me take this a step further. I work with a lot of routing area activities. I do not have spare machine sitting around. I don't have a machine sitting around with a router stack with a set of routing protocols that I can modify. Am I supposed to be prohibited from writing an I-D on a change to a routing protocol? I don't know if my co-authors on the IDR I-D have implemented yet or not. Given that the first question with regard to the I-D was whether the working group thought the problem needed to be addressed, I could well understand someone holding off implementation for a bit. Yours, Joel M. Halpern PS: It is not at all clear to me that this proposal would help the SIP situation much at all. Many of the folks have access to stacks, and could throw together an implementation of their proposal. Not a commercial grade implementation, but enough to claim implementation. And given the strategic importance of SIP, these folks can frequently even get management support for doing the work. At 09:23 AM 3/4/2006, Henry Sinnreich wrote: >Joel, > > > In general, with new work it is pretty hard to require implementation > > of the early stage ideas. > >If the authors of an idea do not invest and commit enough into writing code, >why should they SPAM the WG with I-Ds? Can anyone here stand this flood any >more? > >The idea could still be discussed on e-mail on the list (with a topic title) >without hijacking the IETF brand name to draw attention to themselves. > >The flood of I-Ds that Dean has signaled clearly needs a better control >mechanism and just legitimizing more I-Ds with more WGs is not the answer. > >Maybe there are better self control and stabilization mechanisms to control >the flood of I-Ds and it would be interesting to discuss various options. > >More WGs is not the answer IMHO, a self-regulating preselection mechanism is >the answer: Auto preselection by obligation and commitment to write code >first. > >Dean writes: > > >Lovely idea, but needs to be part of the IETF process, not the SIP process. > >Yes, this is the original IETF process, before the _great flood_ swamped us. > > >The New Track working group, perhaps? >Great idea! The New Track will be a good place to experiment for progress. > >My two cents. Thanks, Henry > > > >-----Original Message----- >From: Marc Petit-Huguenin [mailto:petithug@acm.org] >Sent: Friday, March 03, 2006 7:29 PM >To: Joel M. Halpern >Cc: sip@ietf.org; 'sipping' >Subject: [Sipping] Re: [Sip] Re: Running code > >The way I see it, the I-D can start with an empty Running Code section, >like it is often the case with the IANA or Security section. As the >draft evolves, it can keep track of the various implementation of the >I-D in this section. This could be also a good indicator of the interest >in this work. > >Joel M. Halpern wrote: > > [Sorry, I couldn't let this go without comment. I have trimmed the CC > > so the leadership won't receive 3 copies.] > > > > For SIP, maybe the problem space is in a state where that is practical > > (although I doubt it.) > > > > For many other working groups, it would be really strange to require > > running code before accepting a draft for discussion. For example, in > > ForCES we needed to agree on what the structure of the ForCES protocol > > needed to be. Requiring people to implement ideas that we wanted to > > discuss would have made it very hard to have clear discussion. > > Particularly since we had not agreed on the underlying transport, so it > > would have been easy to confuse transport properties with application > > properties. > > > > In general, with new work it is pretty hard to require implementation of > > the early stage ideas. It can sometimes even be counter-productive. > > Efforts to provide early implementations of alternative management > > structures seemed to cause those emplementors to become wedded to their > > particularl approach. > > > > I definitely like implementation. The routing area is in fact > > increasing the emphasis on implementation before standardization. But > > implementation before I-D seems a mistake. We usually ask folks to > > write up an I-D on anything they want discussed. And in most working > > groups, if the topic is on charter and the approach looks sane, the > > document is often made a WG document to create a clear trackable state > > for the work. > > > > Yours, > > Joel M. Halpern > > > > At 06:34 PM 3/3/2006, Dean Willis wrote: > > > >>> Documents that are only proposals or concepts, but are not backed > >>> up by > >>> running code can be very well exchaged as e-mails on the various > >>> lists. > >>> In this way, WG I-D overload would disappear and Dean's problem > >>> will be > >>> solved. > >>> > >>> If there is no running code, discussions on e-mail is just fine. > >>> > >>> Thanks, Henry > >> > >> > >> Lovely idea, but needs to be part of the IETF process, not the SIP > >> process. The New Track working group, perhaps? > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > >-- >Marc Petit-Huguenin >Home: marc@petit-huguenin.org >Work: marc@8x8.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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 04 11:59:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFa49-0003zZ-EN; Sat, 04 Mar 2006 11:57:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFa48-0003x8-44; Sat, 04 Mar 2006 11:57:12 -0500 Received: from smtp3.wanadoo.co.uk ([193.252.22.156] helo=smtp3.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFa47-0006VR-Bj; Sat, 04 Mar 2006 11:57:12 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3203.me.freeserve.com (SMTP Server) with ESMTP id 68D9F1C00082; Sat, 4 Mar 2006 17:57:08 +0100 (CET) Received: from RW (user-7681.lns1-c7.dsl.pol.co.uk [84.65.158.1]) by mwinf3203.me.freeserve.com (SMTP Server) with SMTP id A369E1C00085; Sat, 4 Mar 2006 17:57:07 +0100 (CET) X-ME-UUID: 20060304165707669.A369E1C00085@mwinf3203.me.freeserve.com Message-ID: <00cd01c63fac$abbf8ce0$0600a8c0@RW> From: "Pete Cordell" To: , "Joel M. Halpern" References: <4408DF2F.7020204@acm.org> <7.0.1.0.0.20060304094900.0328d910@stevecrocker.com> Subject: Re: [Sipping] Re: [Sip] Re: Running code Date: Sat, 4 Mar 2006 16:04:50 -0000 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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: sip@ietf.org, 'sipping' X-BeenThere: sip@ietf.org X-Mailman-Version: 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 2 cents... I've been involved in a number of standardisation efforts that have attempted to track the standard with running code, and I can't say that having running code has helped in any case. Quite often, initial proposals address a specific issue. When they go into the IETF, the IETF quite rightly generalises the issue, most likely morphing it into something completely different and invalidating any code that addressed the specific case. Equally, if you submit a draft, it's quite common for someone to say 'that's not the way to do it,' and produce a counter-proposal thus invalidating your code. Writing code also takes a lot of effort. Testing it in different scenarios is even harder. I personally would rather that effort was put into 'paper-based' exercises to flesh out (and document) the use-cases and identify corner cases etc. Naturally you want running code the instant the RFC is published. That's not just IETF sense, that's business sense! And for anything non-trivial that means code will end up being developed while the proposal is being progressed; which is good from the point of view of developing and validating the proposal. Exactly when you start coding, and how much you commit to it has to be a judgement call though. Overall, I feel if someone has identified a useful feature, then them not having running code should not be a limitation to its progression. Equally, just because someone has running code shouldn't mean a proposal should be progressed. Also, I don't think drafts progress slowly because their authors are not committed to them. My experience of the problem is that it's hard to get debate by third-parties on drafts, which slows progression; possibly because they are writing their own drafts! If the authors (or authors' affiliations) are also required to produce running code, that's going to reduce the effort that they can put into reviewing third-party drafts even more, and I think that will slow things down even more. Maybe that was 3 cents! Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= ----- Original Message ----- From: "Joel M. Halpern" To: Cc: ; "'Marc Petit-Huguenin'" ; "'sipping'" Sent: Saturday, March 04, 2006 3:03 PM Subject: RE: [Sipping] Re: [Sip] Re: Running code > Let's try to separate the pieces. > Having implementations as early as possible is clearly a good idea. > It is sometimes practical to have an implementation along with the first > I-D on a topic. > When it is practical, it is often helpful. > > There are many cases where it is not practical. > There are cases where it is even counter productive. > (As far as I can tell, much of the argument over the proposals in the > OSPF-MANET extensions is because folks are wedded to the proposals they > have implemented, and they have lovely simulations using their code to > show why their answer is better.) > > Part of my concern here is that for all that we need "bits on the wire" to > get things to work, it is often counter-productive to argue about > bits-on-the wire before one agrees on how a protocol ought to behave. > Having an I-D to discuss that describes a particular approach is MUCH > better than just having an email discussion. > In quite a few working groups I work in, the response to an interesting > idea is "give us a draft". That allows the working group to understand > the idea at a suitable level of detail. It would be really bad if that > were only permitted after the person suggesting the idea had built an > implementation. > It is also the case that implementation can be counter-productive. I can > recall a case where a participant in a working group wanted the standard > to essentially require an all-paths graph traversal. Several of us told > him this was a bad idea. He went and implemented and measured it. He > said , roughly ~see, it works and it isn't too expensive.~ It was not too > expensive in his tests, with other limitations, etc. However, there was > no question that it was a bad idea. > Implementation is a good tool. It is not always the right answer. > > I had an implementation of XCAP. I could not and would not have built my > implementation if the I-D had not existed. There was no way I could have > taken the time of product engineers to build something that was not even > an I-D, much less an I-D with some traction in the working group. By > building it, we learned some things that helped shape the work. I am not > arguing that implementation is not a good idea. It is a good idea. But > requiring implementation before the first I-D is difficult and often > counter-productive. > > Let me take this a step further. I work with a lot of routing area > activities. I do not have spare machine sitting around. I don't have a > machine sitting around with a router stack with a set of routing protocols > that I can modify. Am I supposed to be prohibited from writing an I-D on > a change to a routing protocol? I don't know if my co-authors on the IDR > I-D have implemented yet or not. Given that the first question with > regard to the I-D was whether the working group thought the problem needed > to be addressed, I could well understand someone holding off > implementation for a bit. > > Yours, > Joel M. Halpern > > PS: It is not at all clear to me that this proposal would help the SIP > situation much at all. Many of the folks have access to stacks, and could > throw together an implementation of their proposal. Not a commercial > grade implementation, but enough to claim implementation. And given the > strategic importance of SIP, these folks can frequently even get > management support for doing the work. > > At 09:23 AM 3/4/2006, Henry Sinnreich wrote: >>Joel, >> >> > In general, with new work it is pretty hard to require implementation >> > of the early stage ideas. >> >>If the authors of an idea do not invest and commit enough into writing >>code, >>why should they SPAM the WG with I-Ds? Can anyone here stand this flood >>any >>more? >> >>The idea could still be discussed on e-mail on the list (with a topic >>title) >>without hijacking the IETF brand name to draw attention to themselves. >> >>The flood of I-Ds that Dean has signaled clearly needs a better control >>mechanism and just legitimizing more I-Ds with more WGs is not the answer. >> >>Maybe there are better self control and stabilization mechanisms to >>control >>the flood of I-Ds and it would be interesting to discuss various options. >> >>More WGs is not the answer IMHO, a self-regulating preselection mechanism >>is >>the answer: Auto preselection by obligation and commitment to write code >>first. >> >>Dean writes: >> >> >Lovely idea, but needs to be part of the IETF process, not the SIP >> >process. >> >>Yes, this is the original IETF process, before the _great flood_ swamped >>us. >> >> >The New Track working group, perhaps? >>Great idea! The New Track will be a good place to experiment for progress. >> >>My two cents. Thanks, Henry >> >> >> >>-----Original Message----- >>From: Marc Petit-Huguenin [mailto:petithug@acm.org] >>Sent: Friday, March 03, 2006 7:29 PM >>To: Joel M. Halpern >>Cc: sip@ietf.org; 'sipping' >>Subject: [Sipping] Re: [Sip] Re: Running code >> >>The way I see it, the I-D can start with an empty Running Code section, >>like it is often the case with the IANA or Security section. As the >>draft evolves, it can keep track of the various implementation of the >>I-D in this section. This could be also a good indicator of the interest >>in this work. >> >>Joel M. Halpern wrote: >> > [Sorry, I couldn't let this go without comment. I have trimmed the CC >> > so the leadership won't receive 3 copies.] >> > >> > For SIP, maybe the problem space is in a state where that is practical >> > (although I doubt it.) >> > >> > For many other working groups, it would be really strange to require >> > running code before accepting a draft for discussion. For example, in >> > ForCES we needed to agree on what the structure of the ForCES protocol >> > needed to be. Requiring people to implement ideas that we wanted to >> > discuss would have made it very hard to have clear discussion. >> > Particularly since we had not agreed on the underlying transport, so it >> > would have been easy to confuse transport properties with application >> > properties. >> > >> > In general, with new work it is pretty hard to require implementation >> > of >> > the early stage ideas. It can sometimes even be counter-productive. >> > Efforts to provide early implementations of alternative management >> > structures seemed to cause those emplementors to become wedded to their >> > particularl approach. >> > >> > I definitely like implementation. The routing area is in fact >> > increasing the emphasis on implementation before standardization. But >> > implementation before I-D seems a mistake. We usually ask folks to >> > write up an I-D on anything they want discussed. And in most working >> > groups, if the topic is on charter and the approach looks sane, the >> > document is often made a WG document to create a clear trackable state >> > for the work. >> > >> > Yours, >> > Joel M. Halpern >> > >> > At 06:34 PM 3/3/2006, Dean Willis wrote: >> > >> >>> Documents that are only proposals or concepts, but are not backed >> >>> up by >> >>> running code can be very well exchaged as e-mails on the various >> >>> lists. >> >>> In this way, WG I-D overload would disappear and Dean's problem >> >>> will be >> >>> solved. >> >>> >> >>> If there is no running code, discussions on e-mail is just fine. >> >>> >> >>> Thanks, Henry >> >> >> >> >> >> Lovely idea, but needs to be part of the IETF process, not the SIP >> >> process. The New Track working group, perhaps? >> > >> > >> > >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> > >> > >> >> >>-- >>Marc Petit-Huguenin >>Home: marc@petit-huguenin.org >>Work: marc@8x8.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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 05 07:33:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFsO9-0002n5-8M; Sun, 05 Mar 2006 07:31:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFsO7-0002n0-Pj for sip@ietf.org; Sun, 05 Mar 2006 07:31:03 -0500 Received: from m9.hamarashehar.com ([70.86.188.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFsO7-0004jj-Jb for sip@ietf.org; Sun, 05 Mar 2006 07:31:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by m9.hamarashehar.com (Postfix) with ESMTP id 7B3A27C42BA for ; Sun, 5 Mar 2006 06:34:07 -0600 (CST) Received: from m9.hamarashehar.com ([127.0.0.1]) by localhost (m9.hamarashehar.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26490-10 for ; Sun, 5 Mar 2006 06:34:06 -0600 (CST) Received: by m9.hamarashehar.com (Postfix, from userid 48) id 79C957C414E; Sun, 5 Mar 2006 06:34:06 -0600 (CST) Received: from 220.225.175.56 (SquirrelMail authenticated user santosh@renintech.com); by webmail.hamarashehar.com with HTTP; Sun, 5 Mar 2006 06:34:06 -0600 (CST) Message-ID: <3850.220.225.175.56.1141562046.squirrel@webmail.hamarashehar.com> Date: Sun, 5 Mar 2006 06:34:06 -0600 (CST) From: santosh@renintech.com To: sip@ietf.org User-Agent: SquirrelMail/1.4.3a-11.EL3 X-Mailer: SquirrelMail/1.4.3a-11.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at hamarashehar.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] Early Media X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Everybody, I am very new to understanding of SIP. Can any body help me about early media. I am working on a call back ring tones application. I have seen rfc 3959 which talks about 183 response and PRACK request. Is there any another way to do that application. If anybody can help me with a call flow of that i will be very grateful to you all. Thanks in advance. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 05 07:36:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFsRV-0006aW-Qg; Sun, 05 Mar 2006 07:34:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFsRT-0006Xi-OA for sip@ietf.org; Sun, 05 Mar 2006 07:34:31 -0500 Received: from m9.hamarashehar.com ([70.86.188.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFsRT-0004no-IZ for sip@ietf.org; Sun, 05 Mar 2006 07:34:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by m9.hamarashehar.com (Postfix) with ESMTP id 6199D7C42C1 for ; Sun, 5 Mar 2006 06:37:35 -0600 (CST) Received: from m9.hamarashehar.com ([127.0.0.1]) by localhost (m9.hamarashehar.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27010-09 for ; Sun, 5 Mar 2006 06:37:34 -0600 (CST) Received: by m9.hamarashehar.com (Postfix, from userid 48) id 7C60D7C42BA; Sun, 5 Mar 2006 06:37:34 -0600 (CST) Received: from 220.225.175.56 (SquirrelMail authenticated user santosh@renintech.com); by webmail.hamarashehar.com with HTTP; Sun, 5 Mar 2006 06:37:34 -0600 (CST) Message-ID: <3910.220.225.175.56.1141562254.squirrel@webmail.hamarashehar.com> Date: Sun, 5 Mar 2006 06:37:34 -0600 (CST) From: santosh@renintech.com To: sip@ietf.org User-Agent: SquirrelMail/1.4.3a-11.EL3 X-Mailer: SquirrelMail/1.4.3a-11.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at hamarashehar.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] Call Hold X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Everybody, How should we implement the call hold feature in SIP. I know about the method in which IP address i given as 0.0.0.0 to make the call hold and i have also heard that it is not advisable. So is there any better call flow which can do that. Thanks in advance Santosh kumar _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 05 09:07:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFtrP-0006t4-FV; Sun, 05 Mar 2006 09:05:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFtrN-0006sz-OR for sip@ietf.org; Sun, 05 Mar 2006 09:05:21 -0500 Received: from weylernet.com ([212.227.167.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFtrM-0006o8-AO for sip@ietf.org; Sun, 05 Mar 2006 09:05:21 -0500 Received: from WOLVERINE.SOLINET.com [68.163.136.94] by weylernet.com with ESMTP (SMTPD-8.20) id A01B06C4; Sun, 05 Mar 2006 15:05:15 +0100 Message-Id: <6.2.5.6.2.20060305090216.04d4a440@Valid8.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 05 Mar 2006 09:04:41 -0500 To: santosh@renintech.com From: Ian Carpenter Subject: RE: [sip] Call Hold Mime-Version: 1.0 X-Spam-Score: 1.9 (+) 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: , Content-Type: multipart/mixed; boundary="===============0240496805==" Errors-To: sip-bounces@ietf.org --===============0240496805== Content-Type: text/html; charset="us-ascii" Hi Santosh,

I believe using RE-INVITE with a=sendonly attribute in new SDP would be the better way.  Take a look at RFC4317 and see if that helps.

Best regards,
-Ian Carpenter

-----Original Message-----
From: santosh@renintech.com [ mailto:santosh@renintech.com ]
Sent: Sunday, March 05, 2006 7:38 AM
To: sip@ietf.org
Subject: [Sip] Call Hold

  Hi Everybody,

       How should we implement the call hold feature in SIP. I know about the method in which IP address i given as 0.0.0.0 to make the call hold and i have also heard that it is not advisable. So is there any better call flow which can do that.

Thanks in advance

Santosh kumar


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




------------------------------------------------------------------------
Ian Carpenter.
SOLINET  Solutions for Innovative Networks
500 W Cummings Park, Suite #3250, Woburn, MA 01801, USA
Tel +1 781-938-1221 x 102, Fax +1 781-207-0550
Cell +1 415-572-7919, Email I.Carpenter@SOLINET.com
Web www.SOLINET.com --- --===============0240496805== 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 --===============0240496805==-- From sip-bounces@ietf.org Sun Mar 05 09:37:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFuKf-0002GZ-BR; Sun, 05 Mar 2006 09:35:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFuKd-0002GU-JH for sip@ietf.org; Sun, 05 Mar 2006 09:35:35 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFuKc-0007k0-CQ for sip@ietf.org; Sun, 05 Mar 2006 09:35:35 -0500 Received: from 71-81-78-136.dhcp.stls.mo.charter.com ([71.81.78.136] helo=[192.168.30.38]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FFuKc-0003bY-08; Sun, 05 Mar 2006 09:35:34 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.81.78.136 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <440AF733.7030703@sipstation.com> Date: Sun, 05 Mar 2006 08:35:31 -0600 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: santosh@renintech.com Subject: Re: [Sip] Early Media References: <3850.220.225.175.56.1141562046.squirrel@webmail.hamarashehar.com> In-Reply-To: <3850.220.225.175.56.1141562046.squirrel@webmail.hamarashehar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Santosh, Try RFC 3666 for call flows with early media and 183. Thanks, Alan santosh@renintech.com wrote: >Hi Everybody, > I am very new to understanding of SIP. Can any body help me >about early media. I am working on a call back ring tones >application. I have seen rfc 3959 which talks about 183 response >and PRACK request. Is there any another way to do that >application. If anybody can help me with a call flow of that i >will be very grateful to you all. > >Thanks in advance. > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 05 11:22:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFvyW-0006N3-TQ; Sun, 05 Mar 2006 11:20:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFvyV-0006Mi-KX for sip@ietf.org; Sun, 05 Mar 2006 11:20:51 -0500 Received: from web52807.mail.yahoo.com ([206.190.48.250]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFvyU-0002Ar-C2 for sip@ietf.org; Sun, 05 Mar 2006 11:20:51 -0500 Received: (qmail 66104 invoked by uid 60001); 5 Mar 2006 16:20:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SrQK8gXd1YMB1Lg4S/XkBT/IzPNo5cRbzGhQt2wfbtWBTlkRjlck8RPAi1sGS43dD71RqSCbo25qReP5Kfu1hZHyCRr4E3x8YlyDb12sKz/JU+S2xZlxSbXgHHKRILOZx33QZO0U6YxSdeMvNe9f2gHBD8Nl1W3amfDMi8kDsNQ= ; Message-ID: <20060305162049.66102.qmail@web52807.mail.yahoo.com> Received: from [47.248.0.45] by web52807.mail.yahoo.com via HTTP; Sun, 05 Mar 2006 08:20:49 PST Date: Sun, 5 Mar 2006 08:20:49 -0800 (PST) From: Fatih "Eyüp" NAR Subject: RE: [sip] Call Hold To: Ian Carpenter , santosh@renintech.com In-Reply-To: <6.2.5.6.2.20060305090216.04d4a440@Valid8.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 in my opinion: a=sendonly/receiveonly is most likely a "1 way mute" not a complete hold "no streaming at all" , using port=0 in offer may trigger the same action with c=0.0.0.0 in offer. --- Ian Carpenter wrote: --------------------------------- Hi Santosh, I believe using RE-INVITE with a=sendonly attribute in new SDP would bethe better way. Take a look at RFC4317 and see if thathelps. Best regards, -Ian Carpenter -----Original Message----- From: santosh@renintech.com[mailto:santosh@renintech.com] Sent: Sunday, March 05, 2006 7:38 AM To: sip@ietf.org Subject: [Sip] Call Hold Hi Everybody, How should we implement the callhold feature in SIP. I know about the method in which IP address i givenas 0.0.0.0 to make the call hold and i have also heard that it is notadvisable. So is there any better call flow which can do that. Thanks in advance Santosh kumar _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is forNEW development of the core SIP Protocol Usesip-implementors@cs.columbia.edu for questions on current sip Usesipping@ietf.org for new developments on the application of sip --- ------------------------------------------------------------------------ Ian Carpenter. SOLINET Solutions for Innovative Networks 500 W Cummings Park, Suite #3250, Woburn, MA 01801, USA Tel +1 781-938-1221 x 102, Fax +1 781-207-0550 Cell +1 415-572-7919, Email I.Carpenter@SOLINET.com Webwww.SOLINET.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 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 05 21:35:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG5XX-0002Wv-SJ; Sun, 05 Mar 2006 21:33:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG5XX-0002Wi-1n for sip@ietf.org; Sun, 05 Mar 2006 21:33:39 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG5XV-0003HO-Qg for sip@ietf.org; Sun, 05 Mar 2006 21:33:39 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 05 Mar 2006 18:33:37 -0800 X-IronPort-AV: i="4.02,166,1139212800"; d="scan'208"; a="1782087383:sNHT33617000" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k262Xb1j001412; Sun, 5 Mar 2006 18:33:37 -0800 (PST) Received: from 10.21.121.135 ([10.21.121.135]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Mar 2006 02:33:36 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 05 Mar 2006 15:47:57 -0500 From: Cullen Jennings To: "sip@ietf.org" , Message-ID: Thread-Topic: Comment on draft-fwmiller-sip-00 Thread-Index: AcZArzpoeTVf0qyiEdqwhgARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [Sip] Comment on draft-fwmiller-sip-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 really see what this PING method does that OPTIONS does not? If the answer is that this can somehow be optimized in ways that OPTIONS can't, then it is missing all the text to explain that. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 05 21:35:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG5XX-0002Wg-0P; Sun, 05 Mar 2006 21:33:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG5XV-0002PJ-9B for sip@ietf.org; Sun, 05 Mar 2006 21:33:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG5XU-0003HK-0I for sip@ietf.org; Sun, 05 Mar 2006 21:33:37 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 05 Mar 2006 18:33:37 -0800 X-IronPort-AV: i="4.02,166,1139212800"; d="scan'208"; a="259678404:sNHT30294768" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k262XZ1j001408; Sun, 5 Mar 2006 18:33:35 -0800 (PST) Received: from 10.21.121.135 ([10.21.121.135]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Mar 2006 02:33:35 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 05 Mar 2006 15:45:37 -0500 Subject: Re: [Sip] Call Hold From: Cullen Jennings To: , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Call Hold Thread-Index: AcZArub1Ja30EqyiEdqwhgARJEEJ/A== In-Reply-To: <3910.220.225.175.56.1141562254.squirrel@webmail.hamarashehar.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 This question is more difficult than it seems. The problem is that everyone seem to mean different things by the idea of "hold". I will point out that today, when people get put on hold, the often receive very irritating music. Some clarification of all the things that people mean when they say "implement hold" might be be very useful in this discussion. On 3/5/06 4:37 AM, "santosh@renintech.com" wrote: > Hi Everybody, > > How should we implement the call hold feature in SIP. I know about > the method in which IP address i given as 0.0.0.0 to make the call > hold and i have also heard that it is not advisable. So is there > any better call flow which can do that. > > Thanks in advance > > Santosh kumar > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 05 22:26:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG6L8-0002vX-UZ; Sun, 05 Mar 2006 22:24:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG6L8-0002vS-8k for sip@ietf.org; Sun, 05 Mar 2006 22:24:54 -0500 Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG6L6-0004og-BE for sip@ietf.org; Sun, 05 Mar 2006 22:24:54 -0500 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id k263NMZ30020; Mon, 6 Mar 2006 08:53:37 +0530 To: sip-implementors@cs.columbia.edu, "sip@ietf.org" X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: nagendra.swamy@flextronicssoftware.com Date: Mon, 6 Mar 2006 08:53:27 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 03/06/2006 09:01:27 AM MIME-Version: 1.0 X-Spam-Score: 2.3 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Sip] SIP proxy and SIGCOMP X-BeenThere: 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="===============1576485996==" Errors-To: sip-bounces@ietf.org --===============1576485996== Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: base64 PGh0bWw+PGJvZHk+DQo8cD5IaSw8YnI+DQo8YnI+DQpJIGhhdmUgYSBxdWVyeSByZWxhdGluZyB0 byB1c2Ugb2YgU0lHQ09NUCBpbiBTSVAsIGZvciB3aGljaCBJIGNvdWxkIG5vdCBmaW5kIGFueSBp bmZvIGluIHRoZSBTSUdDT01QIHJlbGF0ZWQgUkZDcyBhbmQgZHJhZnRzLiBJZiBhbnlvbmUgaGFz IGFueSBpbmZvLCBraW5kbHkgY2xhcmlmeSB0aGlzIGRvdWJ0Ljxicj4NCkluIGNhc2UgYSBTSVAg cHJveHkgaXMgZm9yd2FyZGluZyBhIHJlcXVlc3QgYmFzZWQgb24gRE5TIGxvb2t1cCAoaS5lLiB0 aGUgY2FsbGVkIHN1YnNjcmliZXIgaWRlbnRpZmllZCBieSB0aGUgUmVxdWVzdCBVUkkgaXMgbm90 IGEgc3Vic2NyaWJlciBvZiB0aGF0IHByb3h5KSwgdGhlbiBpdCB3aWxsIG5vdCByZXBsYWNlIHRo ZSBSZXF1ZXN0IFVSSSBpbiB0aGUgb3V0Z29pbmcgbWVzc2FnZS4gVGhpcyBpcyBhcyBwZXIgUkZD IDMyNjEuIEhvd2V2ZXIsIHdoYXQgc2hvdWxkIGJlIHRoZSBiZWhhdmlvdXIgaW4gc3VjaCBhIGNh c2Ugdy5yLnQgY29tcHJlc3Npb24/IEhvdyBzaG91bGQgdGhlIHByb3h5IGRlY2lkZSB3aGV0aGVy IG9yIG5vdCB0byBjb21wcmVzcyB0aGUgb3V0Z29pbmcgbWVzc2FnZT8gU2hvdWxkIGl0IGxvb2sg Zm9yIGEgJnF1b3Q7Y29tcD1zaWdjb21wJnF1b3Q7IHBhcmFtIGluIHRoZSBpbmNvbWluZyBSZXFV UkkgaW4gb3JkZXIgdG8gbWFrZSB0aGlzIGRlY2lzaW9uPyBJbiBjYXNlIHRoZSBjYWxsZWUgaGFk IGJlZW4gYSBzdWJzY3JpYmVyLCB0aGlzIGRlY2lzaW9uIHdvdWxkIGhhdmUgYmVlbiBtYWRlIGJh c2VkIG9uIHRoZSBwcmVzZW5jZSBvZiB0aGlzIHBhcmFtZXRlciBpbiB0aGUgQ29udGFjdCBoZWFk ZXIgb2YgdGhlIGNhbGxlZS4gVGhpcyBpcyBzcGVjaWZpZWQgYnkgUkZDIDM0ODYuIEhvd2V2ZXIs IFJGQyAzNDg2IGRvZXMgbm90IHNwZWNpZnkgdGhlIGJlaGF2aW91ciB3aGVuIGEgcHJveHkgZG9l cyBub3QgZm9yd2FyZCB0aGUgcmVxdWVzdCBiYXNlZCBvbiBDb250YWN0IGhlYWRlciwgYnV0IGJh c2VkIG9uIHNvbWUgb3RoZXIgbWVhbnMsIHN1Y2ggYXMgRE5TIGxvb2t1cCBvciBzdGF0aWNhbGx5 IGNvbmZpZ3VyZWQgcm91dGVzLCBldGMuPGJyPg0KPGJyPg0KQW55IGhlbHAgd291bGQgYmUgYXBw cmVjaWF0ZWQuPGJyPg0KPGJyPg0KUmVnYXJkczxicj4NCk5hZ2VuZHJhPGJyPg0KPGJyPg0KPGJy Pg0KKioqKioqKioqKioqKioqKioqKioqKiogIEZTUy1SZXN0cmljdGVkICAgKioqKioqKioqKioq KioqKioqKioqKio8L2JvZHk+PC9odG1sPg== --===============1576485996== 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 --===============1576485996==-- From sip-bounces@ietf.org Mon Mar 06 03:31:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGB5w-0000RZ-9D; Mon, 06 Mar 2006 03:29:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGB5u-0000RU-KS for sip@ietf.org; Mon, 06 Mar 2006 03:29:30 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGB5t-0005UW-1m for sip@ietf.org; Mon, 06 Mar 2006 03:29:30 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 500064F0001; Mon, 6 Mar 2006 09:29:28 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 09:29:28 +0100 Received: from [136.225.183.78] ([136.225.183.78]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 09:29:25 +0100 From: "Christer Holmberg" To: "Juha Heinanen" Subject: Re: [Sip] OUTBOUND: Direction of keep-alive requests Date: Mon, 6 Mar 2006 10:24:36 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 06 Mar 2006 08:29:27.0912 (UTC) FILETIME=[153E7680:01C640F8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Juha, I guess it's up to the operator community to decide whether it needs to be = solved. All I am saying is that it is possible, without any new terminal = requirements, for the network to initiate messages to be sent from the UA = towards the NAT. 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 Mon Mar 06 04:21:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBsc-0002mo-3q; Mon, 06 Mar 2006 04:19:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBsa-0002hh-6m for sip@ietf.org; Mon, 06 Mar 2006 04:19:48 -0500 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGBsW-0007bj-PG for sip@ietf.org; Mon, 06 Mar 2006 04:19:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] OUTBOUND: Direction of keep-alive requests Date: Mon, 6 Mar 2006 11:19:37 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606551CE3FE@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] OUTBOUND: Direction of keep-alive requests Thread-Index: AcZA+D3Uv7gTEA+8RkOOAd9Zz2be5wABFnAg From: "David Schwartz" To: "Christer Holmberg" , "Juha Heinanen" X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Juha. I think there is a misunderstanding.=20 If I understand Christer correctly, he is saying that the reason that = network based keep-alive has been ignored is due to the fact that a = comment was made that in some NAT's the keepalive "ping" has to emanate = from "inside" the NAT (i.e. the UA needs to send the keep alive) as = opposed to the network keeping the pinhole open by its constant pinging = from the network side.=20 Your comment that you have not seen this limitation in NAT's only = strengthens Christers claim that a network based keep alive should be = considered as well. Prior to the OUTBOUND approach we had experimented in our network trying = to establish which is more optimal: lowering registration expirations = below binding timeouts and having UA's keep the pinhole open or = alternatively "pinging" from the network. As it turned out, the pinging = approach was way more scalable as sending a packet is "lighter" than = receiving and parsing one. In many cases we even found that to keep = pinhole open a packet from one side was enough. We tried this by setting = keeapalive via to 0.0.0.0 and system scaled even further since we = essentially freed up half the bandwidth associated with the keepalive = ping. I know for a fact that many of the deployed commercial VoIP = networks use this network based approach today. While we could have a discussion on the merits of such an architecture, = I think that if we seek broad adoption of OUTBOUND it is imperative that = OUTBOUND not exclude this approach. As I have mentioned in a previous = posting it is possible to add a network based "ping" without having to = change OUTBOUND all that much. Cheers, David -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: =E1 06 =EE=F8=F5 2006 10:25 To: Juha Heinanen Cc: IETF SIP List Subject: Re: [Sip] OUTBOUND: Direction of keep-alive requests Hi Juha, I guess it's up to the operator community to decide whether it needs to = be solved. All I am saying is that it is possible, without any new = terminal requirements, for the network to initiate messages to be sent = from the UA towards the NAT. 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 Mon Mar 06 04:33:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGC42-0001fA-3H; Mon, 06 Mar 2006 04:31:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGC40-0001f5-OK for sip@ietf.org; Mon, 06 Mar 2006 04:31:36 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGC3y-0000BA-9T for sip@ietf.org; Mon, 06 Mar 2006 04:31:36 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k269VRvq009243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Mar 2006 10:31:27 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k269VM5i012137; Mon, 6 Mar 2006 10:31:22 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k269VDtw012136; Mon, 6 Mar 2006 10:31:13 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: RE: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 From: Hans Persson To: Scott Lawrence In-Reply-To: <1141425703.2954.63.camel@sukothai.pingtel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60AABE56C@zrc2hxm2.corp.nortel.com> <1141399474.2954.42.camel@sukothai.pingtel.com> <1141400301.22882.4.camel@eeek.ingate.se> <1141425703.2954.63.camel@sukothai.pingtel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Mon, 06 Mar 2006 10:31:12 +0100 Message-Id: <1141637472.8398.28.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Mon, 06 Mar 2006 10:31:27 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 fre 2006-03-03 klockan 17:41 -0500 skrev Scott Lawrence: > Yes, that's possible. I wouldn't want to embed the indication in the > body itself; I think that introduces to much ambiguity (did someone on > the path send that X-Comment?). > > We could define a parameter for the Content-Type... > > Content-Type: message/sipfrag;truncated > > It is probably important to specify that if you're going to remove any > Vias, Routes, or Record-Routes, that you always remove those that are > furthest from the system that is returning the error (closest to the > originator of the message). It sounds wise to specify what's suitable to prune in order to be most useful. Perhaps it would be possible to indicate somehow what (how many vias, etc) was removed (at least for routing headers). On the other hand, that assumes that nothing on the way back truncates the message further in order for that information to be useful. It may be better not to go there. Servers that don't like to return information about local topology and want to prune all routing headers could probably still return something like "17 Vias and 2 Record-Routes pruned". The next question is whether that would be more useful than just a regular empty 483. Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 06 05:52:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDI3-0008PZ-3s; Mon, 06 Mar 2006 05:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDI1-0008PU-Rl for sip@ietf.org; Mon, 06 Mar 2006 05:50:09 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGDI0-0003uF-FH for sip@ietf.org; Mon, 06 Mar 2006 05:50:09 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IVP00K01CMZK2@siemenscomms.co.uk> for sip@ietf.org; Mon, 06 Mar 2006 10:47:23 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IVP00J5ACMXF4@siemenscomms.co.uk> for sip@ietf.org; Mon, 06 Mar 2006 10:47:21 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 06 Mar 2006 10:50:05 +0000 Content-return: allowed Date: Mon, 06 Mar 2006 10:50:05 +0000 From: "Elwell, John" To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667083B49BC@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Sip] Updated connected-identity 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="===============0187594126==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0187594126== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_X7svc44+K2oSzCKP8Y7rFg)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_X7svc44+K2oSzCKP8Y7rFg) Content-type: text/plain Content-transfer-encoding: 7BIT draft-elwell-sip-connected-identity is now available: http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.t xt Compared with the 00 version, this has changed considerably and is intended to reflect decisions made in Vancouver. It exploits the ability to change the From URI during a dialog, so that requests in the reverse direction can place the source URI in the From header field and the Identity header can be used to provide authentication, rather having to introduce new headers. Comments would be appreciated. I would like to get this adopted as a SIP WG item in Dallas. John --Boundary_(ID_X7svc44+K2oSzCKP8Y7rFg) Content-type: text/html Content-transfer-encoding: 7BIT Updated connected-identity draft

draft-elwell-sip-connected-identity is now available:
http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.txt

Compared with the 00 version, this has changed considerably and is intended to reflect decisions made in Vancouver. It exploits the ability to change the From URI during a dialog, so that requests in the reverse direction can place the source URI in the From header field and the Identity header can be used to provide authentication, rather having to introduce new headers. Comments would be appreciated. I would like to get this adopted as a SIP WG item in Dallas.

John

--Boundary_(ID_X7svc44+K2oSzCKP8Y7rFg)-- --===============0187594126== 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 --===============0187594126==-- From sip-bounces@ietf.org Mon Mar 06 08:58:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGCn-0004ix-5o; Mon, 06 Mar 2006 08:56:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGCl-0004gC-KU for sip@ietf.org; Mon, 06 Mar 2006 08:56:55 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGGCk-0002nI-Bo for sip@ietf.org; Mon, 06 Mar 2006 08:56:55 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id k26Duo0V014625; Mon, 6 Mar 2006 06:56:51 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] status on the SIP MIB modules? Date: Mon, 6 Mar 2006 06:56:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] status on the SIP MIB modules? Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczA= From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "Romascanu, Dan \(Dan\)" , klingle@cisco.com, Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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 submitted an update to the SIP MIB draft.=20 It addresses the comments we received from the Dan and Juergen of the mib doctors and various nits. The list of changes includes: o removal of SipMethodIdentifier textual convention per MIB doctor feedback o updates of normative references (e.g. RFC 3291 --> RFC 4001) o added a new section to provide a citation to IMPORTed RFCs as they are norm. references We checked the ID text with IDnits (passes clean, no more long lines) and the SMI definitions with SMICng (passes with no errors with the recommended strict options at http://ops.ietf.org/mib-review-tools.html). Kevin and Jean-Francois. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 06 09:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGHj-0000jX-J3; Mon, 06 Mar 2006 09:02:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGHh-0000jR-RS for sip@ietf.org; Mon, 06 Mar 2006 09:02:01 -0500 Received: from tcmail22.telekom.de ([217.6.95.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGGHh-00039V-BW for sip@ietf.org; Mon, 06 Mar 2006 09:02:01 -0500 Received: from g9jbr.mgb01.telekom.de (g9jbr.mgb01.telekom.de [164.20.31.6]) by tcmail21.dmz.telekom.de with ESMTP for sip@ietf.org; Mon, 6 Mar 2006 15:01:59 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Mar 2006 15:01:59 +0100 Message-Id: From: "Alexeitsev, D" To: sip@ietf.org Subject: WG: [Sip] Updated connected-identity draft Date: Mon, 6 Mar 2006 15:01:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: 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="===============1507594362==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1507594362== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64126.72DB9995" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C64126.72DB9995 Content-Type: text/plain Hello Jonh Referring to the open issue about the updated To: header in the final INVITE response: Would it not be possible to have a general solution that would allow both the change of the To: header URI in the final INVITE response, if the COLP information is available at that time, and the midcall change using the UPDATE method? The tests we made with several SIP hard and soft phones show, that the current implementations would accept the changed To: header URI in the final INVITE response without any session influence. The changed To: header URI information would currently not be presented to the user by the UACs, but this is a user interface issue without protocol impact. In the subsequent requests the UACs would still use the original To: header URI, so this could be mentioned in the draft to increase the interoperability with current implementations. Greetings, Denis Alexeistev draft-elwell-sip-connected-identity is now available: http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.txt Compared with the 00 version, this has changed considerably and is intended to reflect decisions made in Vancouver. It exploits the ability to change the From URI during a dialog, so that requests in the reverse direction can place the source URI in the From header field and the Identity header can be used to provide authentication, rather having to introduce new headers. Comments would be appreciated. I would like to get this adopted as a SIP WG item in Dallas. John ------_=_NextPart_001_01C64126.72DB9995 Content-Type: text/html Nachricht
 
Hello Jonh
 
Referring to the open issue about the updated To: header in the final INVITE response:
 
Would it not be possible to have a general solution that would allow both the change of the To: header URI in the final INVITE response, if the COLP information is available at that time, and the midcall change using the UPDATE method?
 
The tests we made with several SIP hard and soft phones show, that the current implementations would accept the changed To: header URI in the final INVITE response without any session influence. The changed To: header URI information would currently not be presented to the user by the UACs, but this is a user interface issue without protocol impact.
 
In the subsequent requests the UACs would still use the original To: header URI, so this could be mentioned in the draft to increase the interoperability with current implementations.
 
Greetings,
Denis Alexeistev
 

draft-elwell-sip-connected-identity is now available:
http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.txt

Compared with the 00 version, this has changed considerably and is intended to reflect decisions made in Vancouver. It exploits the ability to change the From URI during a dialog, so that requests in the reverse direction can place the source URI in the From header field and the Identity header can be used to provide authentication, rather having to introduce new headers. Comments would be appreciated. I would like to get this adopted as a SIP WG item in Dallas.

John

------_=_NextPart_001_01C64126.72DB9995-- --===============1507594362== 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 --===============1507594362==-- From sip-bounces@ietf.org Mon Mar 06 10:03:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHDi-0003zJ-CG; Mon, 06 Mar 2006 10:01:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHDh-0003zE-Hn for sip@ietf.org; Mon, 06 Mar 2006 10:01:57 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGHDf-0005N5-OJ for sip@ietf.org; Mon, 06 Mar 2006 10:01:57 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 5B85919445F for ; Mon, 6 Mar 2006 16:01:54 +0100 (CET) Received: from [192.168.1.77] ([192.168.1.77]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 16:00:21 +0100 Mime-Version: 1.0 (Apple Message framework v623) To: sip@ietf.org List Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-22-141378411 From: Hisham Khartabil Date: Mon, 6 Mar 2006 16:02:15 +0100 X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 06 Mar 2006 15:00:21.0378 (UTC) FILETIME=[B0995E20:01C6412E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Cc: Alan Duric , Dusan Stevanovic Subject: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING request processing? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --Apple-Mail-22-141378411 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I promised to come back with hard real numbers on how long it will take for a server to process and STUN request vs a SIP PING request Myth: processing a STUN request is 10 to 100 times faster than a SIP PING request Assumptions: - SIP PING request is processed early in the stack and bypasses any unnecessary validations. - SIP PING response carries in the contact header the IP address and port as appears in the IP packet (source IP and port). We implemented the PING request as described above in the reSIProcate stack. Attached you will find the c++ file where the changes were made. STUN was already implemented in the reSIProcate stack and used as is. Below you will see the findings: STUN request processing: 0.15 - 0.2 ms SIP PING request processing: 0.1 - 0.2 ms SIP OPTIONS request: 7 ms SIP REGISTER request: 7 ms The measurement was taken between the time a request appeared on ethereal and its response appearing on ethereal. Average was taken manually. As you can see, SIP PING requests were sometimes faster to process that STUN requests, but never slower. Actually the SIP PING requests on average were faster to process. Myth Busted!!!! :) Regards, Hisham P.S. It took 15 mins to modify the sip stack to do the PING response. --Apple-Mail-22-141378411 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0444; name="UdpTransport.cxx" Content-Disposition: attachment; filename=UdpTransport.cxx #if defined(HAVE_CONFIG_H) #include "resip/stack/config.hxx" #endif #include #include "resip/stack/Helper.hxx" #include "resip/stack/SendData.hxx" #include "resip/stack/SipMessage.hxx" #include "resip/stack/UdpTransport.hxx" #include "rutil/Data.hxx" #include "rutil/DnsUtil.hxx" #include "rutil/Logger.hxx" #include "rutil/Socket.hxx" #include "rutil/WinLeakCheck.hxx" #include "rutil/compat.hxx" #include "rutil/stun/Stun.hxx" #define RESIPROCATE_SUBSYSTEM Subsystem::TRANSPORT char *pingStatusLine = "SIP/2.0 200 OK\r\n"; using namespace std; using namespace resip; UdpTransport::UdpTransport(Fifo& fifo, int portNum, IpVersion version, StunSetting stun, const Data& pinterface, AfterSocketCreationFuncPtr socketFunc) : InternalTransport(fifo, portNum, version, pinterface, socketFunc) { InfoLog (<< "Creating UDP transport host=" << pinterface << " port=" << portNum << " ipv4=" << bool(version==V4) ); mTuple.setType(transport()); mFd = InternalTransport::socket(transport(), version); bind(); } UdpTransport::~UdpTransport() { DebugLog (<< "Shutting down " << mTuple); } void UdpTransport::process(FdSet& fdset) { // pull buffers to send out of TxFifo // receive datagrams from fd // preparse and stuff into RxFifo if (mTxFifo.messageAvailable() && fdset.readyToWrite(mFd)) { std::auto_ptr sendData = std::auto_ptr(mTxFifo.getNext()); //DebugLog (<< "Sent: " << sendData->data); //DebugLog (<< "Sending message on udp."); assert( &(*sendData) ); assert( sendData->destination.getPort() != 0 ); const sockaddr& addr = sendData->destination.getSockaddr(); int count = sendto(mFd, sendData->data.data(), sendData->data.size(), 0, // flags &addr, sendData->destination.length()); if ( count == SOCKET_ERROR ) { int e = getErrno(); error(e); InfoLog (<< "Failed (" << e << ") sending to " << sendData->destination); fail(sendData->transactionId); } else { if (count != int(sendData->data.size()) ) { ErrLog (<< "UDPTransport - send buffer full" ); fail(sendData->transactionId); } } } // !jf! this may have to change - when we read a message that is too big if ( fdset.readyToRead(mFd) ) { //should this buffer be allocated on the stack and then copied out, as it //needs to be deleted every time EWOULDBLOCK is encountered // .dlb. can we determine the size of the buffer before we allocate? // something about MSG_PEEK|MSG_TRUNC in Stevens.. // .dlb. RFC3261 18.1.1 MUST accept 65K datagrams. would have to attempt to // adjust the UDP buffer as well... char* buffer = MsgHeaderScanner::allocateBuffer(MaxBufferSize); // !jf! how do we tell if it discarded bytes // !ah! we use the len-1 trick :-( Tuple tuple(mTuple); socklen_t slen = tuple.length(); int len = recvfrom( mFd, buffer, MaxBufferSize, 0 /*flags */, &tuple.getMutableSockaddr(), &slen); if ( len == SOCKET_ERROR ) { int err = getErrno(); if ( err != EWOULDBLOCK ) { error( err ); } } if (len == 0 || len == SOCKET_ERROR) { delete[] buffer; buffer=0; return; } if (len+1 >= MaxBufferSize) { InfoLog(<<"Datagram exceeded max length "<\r\n", Tuple::inet_ntop(tuple).c_str(), tuple.getPort()); int contactLen = strlen(contact); memcpy(pingResponse, contact, contactLen); pingResponseLen += contactLen; memcpy(&pingResponse[pingResponseLen], body, bodyLen); pingResponseLen += bodyLen; SendData *pingData = new SendData(tuple, pingResponse, pingResponseLen); mTxFifo.add(pingData); return; } //DebugLog ( << "UDP Rcv : " << len << " b" ); //DebugLog ( << Data(buffer, len).escaped().c_str()); SipMessage* message = new SipMessage(this); // set the received from information into the received= parameter in the // via // It is presumed that UDP Datagrams are arriving atomically and that // each one is a unique SIP message // Save all the info where this message came from tuple.transport = this; message->setSource(tuple); //DebugLog (<< "Received from: " << tuple); // Tell the SipMessage about this datagram buffer. message->addBuffer(buffer); mMsgHeaderScanner.prepareForMessage(message); char *unprocessedCharPtr; if (mMsgHeaderScanner.scanChunk(buffer, len, &unprocessedCharPtr) != MsgHeaderScanner::scrEnd) { StackLog(<<"Scanner rejecting datagram as unparsable / fragmented from " << tuple); StackLog(<< Data(buffer, len)); delete message; message=0; return; } // no pp error int used = unprocessedCharPtr - buffer; if (used < len) { // body is present .. add it up. // NB. The Sip Message uses an overlay (again) // for the body. It ALSO expects that the body // will be contiguous (of course). // it doesn't need a new buffer in UDP b/c there // will only be one datagram per buffer. (1:1 strict) message->setBody(buffer+used,len-used); //DebugLog(<<"added " << len-used << " byte body"); } if (!basicCheck(*message)) { delete message; // cannot use it, so, punt on it... // basicCheck queued any response required message = 0; return; } stampReceived(message); mStateMachineFifo.add(message); } } void UdpTransport::buildFdSet( FdSet& fdset ) { fdset.setRead(mFd); if (mTxFifo.messageAvailable()) { fdset.setWrite(mFd); } } /* ==================================================================== * The Vovida Software License, Version 1.0 * * Copyright (c) 2000 Vovida Networks, Inc. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution. * * 3. The names "VOCAL", "Vovida Open Communication Application Library", * and "Vovida Open Communication Application Library (VOCAL)" must * not be used to endorse or promote products derived from this * software without prior written permission. For written * permission, please contact vocal@vovida.org. * * 4. Products derived from this software may not be called "VOCAL", nor * may "VOCAL" appear in their name, without prior written * permission of Vovida Networks, Inc. * * THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND * NON-INFRINGEMENT ARE DISCLAIMED. IN NO EVENT SHALL VOVIDA * NETWORKS, INC. OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT DAMAGES * IN EXCESS OF $1,000, NOR FOR ANY INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH * DAMAGE. * * ==================================================================== * * This software consists of voluntary contributions made by Vovida * Networks, Inc. and many individuals on behalf of Vovida Networks, * Inc. For more information on Vovida Networks, Inc., please see * . * */ --Apple-Mail-22-141378411 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 --Apple-Mail-22-141378411-- From sip-bounces@ietf.org Mon Mar 06 10:26:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHZs-0004q4-6Q; Mon, 06 Mar 2006 10:24:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHZq-0004pz-Pe for sip@ietf.org; Mon, 06 Mar 2006 10:24:50 -0500 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGHZp-0005pf-Ia for sip@ietf.org; Mon, 06 Mar 2006 10:24:50 -0500 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k26FOkn11391; Mon, 6 Mar 2006 09:24:46 -0600 Date: Mon, 6 Mar 2006 09:24:46 -0600 Message-Id: <200603061524.k26FOkn11391@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: "Cullen Jennings" , "sip@ietf.org" , fwmiller@cornfed.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Sip] RE: Comment on draft-fwmiller-sip-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 would point you at the most recent version, -01. The new version does away with the retransmission requirements. The UAC sends a single PING to a UAS. If a response is not received within a timeout, the application is notified and can decide for itself whether to retransmit. This is definitely different than OPTIONS. This makes it look something like an ICMP ping. Other than that tho, there is a lot of similarity. I has also been mentioned that since there is explicitly no body allowed and the attempt to minimize the headers, the potential for optimizations in an implementation is greater. FM P.S. Looking at it again, I mentioned an expiration interval before reporting that the ping was not responded to but did not actually specify a duration :( Suggestions? I'm thinking like 500 ms? ------------------------------------------------ On Sun, 05 Mar 2006 15:47:57 -0500, Cullen Jennings wrote: > > I don't really see what this PING method does that OPTIONS does not? If the > answer is that this can somehow be optimized in ways that OPTIONS can't, > then it is missing all the text to explain that. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 06 10:42:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHp7-0007qg-W0; Mon, 06 Mar 2006 10:40:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHp6-0007pp-1S for sip@ietf.org; Mon, 06 Mar 2006 10:40:36 -0500 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGHjd-00067v-WA for sip@ietf.org; Mon, 06 Mar 2006 10:35:00 -0500 Received: from sonusmail02.sonusnet.com (sonusmail02.sonusnet.com [10.128.32.96]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k26FYv4Q030933; Mon, 6 Mar 2006 10:34:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING requestprocessing? Date: Mon, 6 Mar 2006 10:34:56 -0500 Message-ID: <05AE95C39E8E2642AF9C04526EDAC414B49A60@sonusmail02.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING requestprocessing? Thread-Index: AcZBLvIuRHkxEi2lR/y+U+ZHuXL7YgAAZaYQ From: "Bharrat, Shaun" To: "Hisham Khartabil" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hisham: Glad to see actual code and test results. It is a _welcome_ sight to have full information and numbers based on real code. Now that I understand what is actually being done, I guess my question is why you would have expected the numbers to be any different? Please correct me if I am misunderstanding=20 anything in what you have done. This is not doing ANY sip=20 processing - it just finds the first \r\n and then copies=20 everything beyond that (with a 200 + contact header prepended)=20 into the response. There is no VIA processing (guess we don't need to add received=3D or rport?), no Content-Length processing=20 (how does it work for TCP?), etc. If we are "allowed" to skip the SIP processing (i.e. it's not really a SIP packet), then I agree that we can make the processing time of a PING arbitrarily close to a STUN packet processing. However, if we are not, I don't agree that this is a valid comparison of a SIP-based keepalive versus a=20 STUN based keepalive. My 2c Thanks and cheers, Shaun www.sonusnet.com > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, March 06, 2006 10:02 AM > To: sip@ietf.org List > Cc: Alan Duric; Dusan Stevanovic > Subject: [Sip] Myth Busters: Episode 1,Is STUN request=20 > processing faster > than a SIP PING requestprocessing? >=20 >=20 > I promised to come back with hard real numbers on how long it=20 > will take=20 > for a server to process and STUN request vs a SIP PING request >=20 > Myth: processing a STUN request is 10 to 100 times faster than a SIP=20 > PING request >=20 > Assumptions: - SIP PING request is processed early in the stack and=20 > bypasses any unnecessary validations. > - SIP PING response carries in the contact=20 > header the IP=20 > address and port as appears in the IP packet (source IP and port). >=20 > We implemented the PING request as described above in the reSIProcate=20 > stack. Attached you will find the c++ file where the changes=20 > were made. > STUN was already implemented in the reSIProcate stack and used as is. >=20 > Below you will see the findings: >=20 > STUN request processing: 0.15 - 0.2 ms > SIP PING request processing: 0.1 - 0.2 ms > SIP OPTIONS request: 7 ms > SIP REGISTER request: 7 ms >=20 > The measurement was taken between the time a request appeared on=20 > ethereal and its response appearing on ethereal. Average was taken=20 > manually. >=20 > As you can see, SIP PING requests were sometimes faster to=20 > process that=20 > STUN requests, but never slower. Actually the SIP PING requests on=20 > average were faster to process. >=20 > Myth Busted!!!! :) >=20 > Regards, > Hisham > P.S. It took 15 mins to modify the sip stack to do the PING response. >=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 Mar 06 10:43:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHpx-0000VD-MF; Mon, 06 Mar 2006 10:41:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHp6-0007oX-GC for sip@ietf.org; Mon, 06 Mar 2006 10:40:36 -0500 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGHix-00065k-UG for sip@ietf.org; Mon, 06 Mar 2006 10:34:16 -0500 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k26FYDn12431; Mon, 6 Mar 2006 09:34:13 -0600 Date: Mon, 6 Mar 2006 09:34:13 -0600 Message-Id: <200603061534.k26FYDn12431@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: fwmiller@cornfed.com, "Cullen Jennings" , "sip@ietf.org" Subject: RE: [Sip] RE: Comment on draft-fwmiller-sip-00 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 > > P.S. Looking at it again, I mentioned an expiration interval before reporting that the ping was not responded to but did not actually specify a duration :( Suggestions? I'm thinking like 500 ms? Whups, I take it back, the -01 version contains a 5 sec expiration interval. This might be too long, thoughts on this expiration? 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 Mon Mar 06 10:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHqn-0001jR-6d; Mon, 06 Mar 2006 10:42:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHql-0001iC-Ca for sip@ietf.org; Mon, 06 Mar 2006 10:42:19 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGHqj-0006k0-Ps for sip@ietf.org; Mon, 06 Mar 2006 10:42:19 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k26FgFu7022167; Mon, 6 Mar 2006 16:42:15 +0100 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 k26FgFmi001830; Mon, 6 Mar 2006 16:42:15 +0100 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 16:42:15 +0100 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: AW: [Sip] draft ietf-sip-target-dialog provisionally approved by IESG Date: Mon, 6 Mar 2006 16:42:13 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft ietf-sip-target-dialog provisionally approved by IESG Thread-Index: AcY+SeNpTDQ928zESeSD9CpIZGCI6AC6fQUg From: "Tan, Ya-Ching" To: "sip ietf" X-OriginalArrivalTime: 06 Mar 2006 15:42:15.0162 (UTC) FILETIME=[8AEE5DA0:01C64134] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Some late comments : - The texts state that the dialog identifiers for the Target-Dialog = header MUST contain the "call-id", "local-tag" and "remote-tag". I = wonder why the header is not defined to treat all these mandatory = components equally (eg. Target-Dialog : = call-id=3Dfa77as7dad8-sd98ajzz@host.example.com, local-tag=3Dkkaz, = remote-tag=3D6544). The current BNF definition implies that the = "local-tag" and "remote-tag" are optional parameters of the header, = which is misleading. - Figure 4 shows that a proxy (acting as a proxy) can add ("a") or = remove ("r") a Target-Dialog header. Shouldn't it be left blank there = (like for the In-Reply-To header in RFC 3261) ? - In the example on on Page 12, the REFER is shown to contain an Event = header. REFERs normally have no Event header, as this subscription is = implicit. =20 Ya Ching -----Urspr=FCngliche Nachricht----- Von: Dean Willis [mailto:dean.willis@softarmor.com]=20 Gesendet: Donnerstag, 2. M=E4rz 2006 23:37 An: sip ietf Betreff: [Sip] draft ietf-sip-target-dialog provisionally approved by = IESG Congratulations yet again. The target-dialog draft has been approved by the IESG. Final =20 announcement is pending an AD writeup to fix a couple of nits with =20 Instructions to the RFC Editor. One of these nits is that the draft uses RFC 2119 language (MUST), =20 but failed to include a reference to 2119, which it MUST do. =20 Something to watch for in future drafts -- idnits currently doesn'n't =20 catch this, and I've asked Henrik to look into adding this in a =20 future idnist rev. -- 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 Mar 06 11:20:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIQI-0004nE-O2; Mon, 06 Mar 2006 11:19:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIQF-0004mx-Fr for sip@ietf.org; Mon, 06 Mar 2006 11:18:59 -0500 Received: from ptr-64-201-174-137.ptr.terago.ca ([64.201.174.137] helo=cgy01-fw01.citel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGIQE-0008Go-62 for sip@ietf.org; Mon, 06 Mar 2006 11:18:59 -0500 Received: from [10.7.1.3] (helo=not01-mxc01.citel.com) by cgy01-fw01.citel.com with esmtp (Exim 4.43) id 1FGIQ3-0004zX-Tg; Mon, 06 Mar 2006 09:18:48 -0700 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: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING requestprocessing? Date: Mon, 6 Mar 2006 16:18:51 -0000 Message-ID: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6CFC@not01-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PINGrequestprocessing? Thread-Index: AcZBLvIuRHkxEi2lR/y+U+ZHuXL7YgAAZaYQAAIVvJA= From: "Michael Procter" To: "Bharrat, Shaun" , "Hisham Khartabil" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Bharrat, Shaun wrote: > Now that I understand what is actually being done, I guess > my question is why you would have expected the numbers to > be any different? [...] > If we are "allowed" to skip the SIP processing (i.e. it's > not really a SIP packet), then I agree that we can make the > processing time of a PING arbitrarily close to a STUN packet > processing. However, if we are not, I don't agree that this > is a valid comparison of a SIP-based keepalive versus a=20 > STUN based keepalive. I think the point is that the message has sufficient SIP headers that it can be parsed and rejected (501) by a stack that doesn't support the extension. A rejection is an acceptable response to the PING request,=20 So, the PING request is in some sense backwards-compatible with existing code. Of course, newer implementations may choose to optimise the processing for it, so that they can get performance that is equivalent to STUN, but there is no need to do so for the feature to work. Implementing the fast-path processing is therefore purely an implementation issue, not a protocol compliance issue. Regards, Michael Procter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 06 11:38:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIhS-00039A-HO; Mon, 06 Mar 2006 11:36:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIhR-000395-Hx for sip@ietf.org; Mon, 06 Mar 2006 11:36:45 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGIhR-0000Zb-0K for sip@ietf.org; Mon, 06 Mar 2006 11:36:45 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IVP00J01SOKYN@siemenscomms.co.uk> for sip@ietf.org; Mon, 06 Mar 2006 16:33:57 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IVP00J79SN8F1@siemenscomms.co.uk>; Mon, 06 Mar 2006 16:33:08 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 06 Mar 2006 16:35:52 +0000 Content-return: allowed Date: Mon, 06 Mar 2006 16:35:51 +0000 From: "Elwell, John" Subject: RE: [Sip] Updated connected-identity draft To: "Alexeitsev, D" Message-id: <50B1CBA96870A34799A506B2313F26670841CE66@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 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="===============0297537659==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0297537659== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_vIcSU/l/LTb1j00qJYUOAQ)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_vIcSU/l/LTb1j00qJYUOAQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Denis, =20 The disadvantage with changing the To header field URI in the INVITE response is that authentication using the Identity header cannot be achieved. It may be possible to rely on other means to ensure the authenticity of this information (e.g., SIPS + transitive trust +use of = TLS on the last hop too). It depends whether there is sufficient interest = from the community in this. =20 John _____ =20 From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 Sent: 06 March 2006 13:57 To: Elwell, John Cc: sip@ietf.org Subject: AW: [Sip] Updated connected-identity draft Hello Jonh =20 Referring to the open issue about the updated To: header in the final = INVITE response: =20 Would it not be possible to have a general solution that would allow = both the change of the To: header URI in the final INVITE response, if the = COLP information is available at that time, and the midcall change using the UPDATE method? =20 The tests we made with several SIP hard and soft phones show, that the current implementations would accept the changed To: header URI in the = final INVITE response without any session influence. The changed To: header = URI information would currently not be presented to the user by the UACs, = but this is a user interface issue without protocol impact. =20 In the subsequent requests the UACs would still use the original To: = header URI, so this could be mentioned in the draft to increase the interoperability with current implementations. =20 Greetings, Denis Alexeistev -----Urspr=FCngliche Nachricht----- Von: Elwell, John [mailto:john.elwell@siemens.com]=20 Gesendet: Montag, 6. M=E4rz 2006 11:50 An: sip@ietf.org Betreff: [Sip] Updated connected-identity draft draft-elwell-sip-connected-identity is now available:=20 =20 http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-= 01.t xt=20 Compared with the 00 version, this has changed considerably and is = intended to reflect decisions made in Vancouver. It exploits the ability to = change the From URI during a dialog, so that requests in the reverse direction = can place the source URI in the From header field and the Identity header = can be used to provide authentication, rather having to introduce new headers. Comments would be appreciated. I would like to get this adopted as a = SIP WG item in Dallas. John=20 --Boundary_(ID_vIcSU/l/LTb1j00qJYUOAQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Nachricht
Denis,
 
The disadvantage with changing the To header= field URI in=20 the INVITE response is that authentication using the Identity header = cannot be=20 achieved. It may be possible to rely on other means to ensure the aut= henticity=20 of this information (e.g., SIPS + transitive trust +use of TLS on the= last hop=20 too). It depends whether there is sufficient interest from the commun= ity in=20 this.
 
John

From: Alexeitsev, D=20 [mailto:D.Alexeitsev@t-com.net]
Sent: 06 March 2006=20 13:57
To: Elwell, John
Cc: sip@ietf.org
S= ubject:=20 AW: [Sip] Updated connected-identity draft

Hello Jonh
 
Referring to the open issue about the updated To: header i= n the final=20 INVITE response:
 
Would it not be possible to have a general solution that w= ould allow=20 both the change of the To: header URI in the final INVITE response,= if the=20 COLP information is available at that time, and the midcall change = using the=20 UPDATE method?
 
The=20 tests we made with several SIP hard and soft phones show, that the = current=20 implementations would accept the changed To: header URI in the fina= l INVITE=20 response without any session influence. The changed To: header URI = information=20 would currently not be presented to the user by the UACs, but this = is a user=20 interface issue without protocol impact.
 
In=20 the subsequent requests the UACs would still use the original To: h= eader URI,=20 so this could be mentioned in the draft to increase the intero= perability=20 with current implementations.
 
Greetings,
Denis Alexeistev
-----Urspr=FCngliche Nachricht---= --
Von:=20 Elwell, John [mailto:john.elwell@siemens.com]
Gesendet: = Montag, 6.=20 M=E4rz 2006 11:50
An: sip@ietf.org
Betreff: [Si= p] Updated=20 connected-identity draft

draft-elwell-sip-connected-identit= y is now=20 available:
http://www.ietf.org/internet-drafts/draft-elwell-sip-con= nected-identity-01.txt=20

Compared with the 00 version, this= has changed=20 considerably and is intended to reflect decisions made in Vancouv= er. It=20 exploits the ability to change the From URI during a dialog, so t= hat=20 requests in the reverse direction can place the source URI in the= From=20 header field and the Identity header can be used to provide authe= ntication,=20 rather having to introduce new headers. Comments would be appreci= ated. I=20 would like to get this adopted as a SIP WG item in Dallas.=

John=20

--Boundary_(ID_vIcSU/l/LTb1j00qJYUOAQ)-- --===============0297537659== 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 --===============0297537659==-- From sip-bounces@ietf.org Mon Mar 06 12:50:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGJpF-0002UM-IG; Mon, 06 Mar 2006 12:48:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGJpD-0002SI-Iz for sip@ietf.org; Mon, 06 Mar 2006 12:48:51 -0500 Received: from firewall.objectworld.com ([72.1.207.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGJpC-00036f-3x for sip@ietf.org; Mon, 06 Mar 2006 12:48:51 -0500 Received: from photon.objectworld.com (photon.objectworld.com [192.168.1.2]) by firewall.objectworld.com (8.12.11/8.12.11) with ESMTP id k26HmXlg001068 for ; Mon, 6 Mar 2006 12:48:48 -0500 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] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING requestprocessing? (P2PSIP possibilities) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Mar 2006 12:48:27 -0500 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C528C598@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING requestprocessing? (P2PSIP possibilities) Thread-Index: AcZBLvIuRHkxEi2lR/y+U+ZHuXL7YgAAZaYQAAShEwA= From: "Michael Slavitch" To: "Bharrat, Shaun" , "Hisham Khartabil" , X-Spam-Score: 0.00 () [Tag at 15.00] X-CanItPRO-Stream: outgoing Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.1.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: p2p-sip@cs.columbia.edu, Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hisham;=0A= =0A= Love the code and the numbers. We'll try our luck here and compare. This=0A= is the first time in a long time that our engineers and our testers were=0A= equally happy (and not grumpy) after I forwarded them an email from an=0A= IETF WG list.=20=20=0A= =0A= I hope that this is the start of a trend. It allows us to ask and answer=0A= firm questions with real data in real implementations.=0A= =0A= On another note, if 'it was not really part of SIP', but part of a 'P2P=0A= Overlay mechanism' a lot of difficult things would begin to go away,=0A= especially if part of the capability of P2PSIP offered a client adaptor=0A= service for low-function SIP user agents or proxies. For that reason I'm=0A= forwarding this email to the p2psip list, as people there will have an=0A= interest in this discussion and especially the sample code and the test=0A= results.=0A= =0A= http://mice.cs.columbia.edu/getTechreport.php?techreportID=3D388 has an=0A= interesting description of client adaptors in a peer to peer=0A= environment, something that would offer great benefit if implemented in=0A= P2PSIP.=0A= =0A= =0A= Regards=0A= =0A= Michael=0A= =0A= =0A= Michael Slavitch Lead, Strategic Initiatives=20=0A= slavitch@objectworld.com Objectworld Communications Corp.=20=0A= +1.613.599.9698 .225 Ottawa, Ontario, Canada=0A= =0A= -----Original Message-----=0A= From: Bharrat, Shaun [mailto:SBharrat@sonusnet.com]=20=0A= Sent: March 6, 2006 10:35 AM=0A= To: Hisham Khartabil; sip@ietf.org=0A= Cc: Alan Duric; Dusan Stevanovic=0A= Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN request processing=0A= faster than a SIP PING requestprocessing?=0A= =0A= Hisham:=0A= =0A= Glad to see actual code and test results. It is a _welcome_ sight to=0A= have full information and numbers based on real code.=0A= =0A= Now that I understand what is actually being done, I guess my question=0A= is why you would have expected the numbers to be any different? Please=0A= correct me if I am misunderstanding anything in what you have done. This=0A= is not doing ANY sip processing - it just finds the first \r\n and then=0A= copies everything beyond that (with a 200 + contact header prepended)=0A= into the response. There is no VIA processing (guess we don't need to=0A= add received=3D or rport?), no Content-Length processing (how does it work= =0A= for TCP?), etc.=0A= =0A= If we are "allowed" to skip the SIP processing (i.e. it's not really a=0A= SIP packet), then I agree that we can make the processing time of a PING=0A= arbitrarily close to a STUN packet processing. However, if we are not, I=0A= don't agree that this is a valid comparison of a SIP-based keepalive=0A= versus a STUN based keepalive.=0A= =0A= My 2c=0A= =0A= Thanks and cheers,=0A= Shaun=0A= =0A= www.sonusnet.com=0A= =0A= > -----Original Message-----=0A= > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=0A= > Sent: Monday, March 06, 2006 10:02 AM=0A= > To: sip@ietf.org List=0A= > Cc: Alan Duric; Dusan Stevanovic=0A= > Subject: [Sip] Myth Busters: Episode 1,Is STUN request processing=20=0A= > faster than a SIP PING requestprocessing?=0A= >=20=0A= >=20=0A= > I promised to come back with hard real numbers on how long it will=20=0A= > take for a server to process and STUN request vs a SIP PING request=0A= >=20=0A= > Myth: processing a STUN request is 10 to 100 times faster than a SIP=20= =0A= > PING request=0A= >=20=0A= > Assumptions: - SIP PING request is processed early in the stack and=20= =0A= > bypasses any unnecessary validations.=0A= > - SIP PING response carries in the contact header the=20= =0A= > IP address and port as appears in the IP packet (source IP and port).=0A= >=20=0A= > We implemented the PING request as described above in the reSIProcate=20= =0A= > stack. Attached you will find the c++ file where the changes were=20=0A= > made.=0A= > STUN was already implemented in the reSIProcate stack and used as is.=0A= >=20=0A= > Below you will see the findings:=0A= >=20=0A= > STUN request processing: 0.15 - 0.2 ms SIP PING request processing:=20=0A= > 0.1 - 0.2 ms SIP OPTIONS request: 7 ms SIP REGISTER request: 7 ms=0A= >=20=0A= > The measurement was taken between the time a request appeared on=20=0A= > ethereal and its response appearing on ethereal. Average was taken=20=0A= > manually.=0A= >=20=0A= > As you can see, SIP PING requests were sometimes faster to process=20=0A= > that STUN requests, but never slower. Actually the SIP PING requests=20= =0A= > on average were faster to process.=0A= >=20=0A= > Myth Busted!!!! :)=0A= >=20=0A= > Regards,=0A= > Hisham=0A= > P.S. It took 15 mins to modify the sip stack to do the PING response.=0A= >=20=0A= >=20=0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0A= sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=0A= =0A= =0A= -----------------------------------------------=0D=0A= =0D=0A= This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D=0A= =0D=0A= Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20=0A= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 06 13:41:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKbw-0002AZ-Tb; Mon, 06 Mar 2006 13:39:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKbv-0002AU-Fj for sip@ietf.org; Mon, 06 Mar 2006 13:39:11 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGKbu-00052k-5d for sip@ietf.org; Mon, 06 Mar 2006 13:39:11 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 06 Mar 2006 10:39:05 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="1782299267:sNHT1389935024" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k26Id3Gv011663; Mon, 6 Mar 2006 10:39:04 -0800 (PST) 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.211); Mon, 6 Mar 2006 13:39:03 -0500 Received: from [192.168.1.101] ([10.86.240.173]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 13:39:03 -0500 Message-ID: <440C81C6.6000601@cisco.com> Date: Mon, 06 Mar 2006 13:39:02 -0500 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: "Tan, Ya-Ching" Subject: Re: AW: [Sip] draft ietf-sip-target-dialog provisionally approved by IESG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2006 18:39:03.0433 (UTC) FILETIME=[3DF40F90:01C6414D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Tan, Ya-Ching wrote: > > Some late comments : > > - The texts state that the dialog identifiers for the Target-Dialog > header MUST contain the "call-id", "local-tag" and "remote-tag". I > wonder why the header is not defined to treat all these mandatory > components equally (eg. Target-Dialog : > call-id=fa77as7dad8-sd98ajzz@host.example.com, local-tag=kkaz, > remote-tag=6544). Either way would work. Generally, header fields have values and then parameters separated by semicolons. If you did what you propose above, you'd have to make up something to put in the value, for example * or something. May as well put call-id in there. In any case, as you know the draft has been approved already so this kind of change couldn't really be made at this point. Bugs and fixes like that are OK, but a design change wouldn't be appropriate. The current BNF definition implies that the > "local-tag" and "remote-tag" are optional parameters of the header, > which is misleading. BNF cannot express all constraints. Here, we want all parameters to be present, but with arbitrary order. That is VERY hard to write in a bnf, and lends no clarity if you do it. The spec is quite explicit that all must be present. We have had this situation in many specifications, and always we use BNF to help specify the grammar of the messages, not the full set of constraints on the protocol. > > - Figure 4 shows that a proxy (acting as a proxy) can add ("a") or > remove ("r") a Target-Dialog header. Shouldn't it be left blank there > (like for the In-Reply-To header in RFC 3261) ? I think you're probably right, this is a bug. This we can correct during auth48. I'll make a note. > > - In the example on on Page 12, the REFER is shown to contain an > Event header. REFERs normally have no Event header, as this > subscription is implicit. Right, another bug. Will fix during auth48. Thanks for the 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 Mon Mar 06 14:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKvN-0001pn-1R; Mon, 06 Mar 2006 13:59:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKvL-0001nG-Ah for sip@ietf.org; Mon, 06 Mar 2006 13:59:15 -0500 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 1FGKvJ-0005gi-Vf for sip@ietf.org; Mon, 06 Mar 2006 13:59:15 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 06 Mar 2006 10:59:13 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="312029045:sNHT34742220" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k26IxCw1027587; Mon, 6 Mar 2006 10:59:13 -0800 (PST) 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.211); Mon, 6 Mar 2006 13:59:09 -0500 Received: from [192.168.1.101] ([10.86.240.173]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 13:59:08 -0500 Message-ID: <440C867B.6060506@cisco.com> Date: Mon, 06 Mar 2006 13:59:07 -0500 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: Michael Procter Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING requestprocessing? References: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6CFC@not01-mxc01.citel.com> In-Reply-To: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6CFC@not01-mxc01.citel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2006 18:59:08.0722 (UTC) FILETIME=[0C5C9120:01C64150] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org, "Bharrat, Shaun" , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 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. Michael Procter wrote: > Bharrat, Shaun wrote: > >>Now that I understand what is actually being done, I guess >>my question is why you would have expected the numbers to >>be any different? > > [...] > >>If we are "allowed" to skip the SIP processing (i.e. it's >>not really a SIP packet), then I agree that we can make the >>processing time of a PING arbitrarily close to a STUN packet >>processing. However, if we are not, I don't agree that this >>is a valid comparison of a SIP-based keepalive versus a >>STUN based keepalive. > > > I think the point is that the message has sufficient SIP headers > that it can be parsed and rejected (501) by a stack that doesn't > support the extension. A rejection is an acceptable response > to the PING request, > > So, the PING request is in some sense backwards-compatible with > existing code. Thats my beef with this whole thing. That its "in some sense" backwards compatible, but not really. You are taking something that LOOKS like SIP, but is fundamentally NOT SIP, and sending to a server in the hopes that the right thing happens. However, in the real world, odd things will always happen. Let me give some examples. UAC sends the PING request to its proxy. Proxy doesnt support the method but forwards it on to another proxy, ignorning max-forwards (some elements do this, as they serve as 'fronts' to the real proxy). Packet is lost. Well, you've changed the retransmit rules for PING from normal SIP, and there are no retransmits. So, there is a timeout. We'll have a nice race condition, first of all, since the outbound proxy, having thought this was normal SIP, will generate a 408 at some point, but probably after the UAC gives up. Depends on how you define your new PING protocol transaction timers relative to real sip. Assuming though that the UAC times out first, the UAC will think that its proxy is down, but its not. Seems really bad to me. Here's another funny case. PING goes to a proxy, which doesn't know about PING, but wants to authenticate the request. So, it responds with a 401 and challenges the request. Well, you might say it worked fine - nat binding kept alive. However, many proxies will set off alarms with their intrusion detection systems on repeated 401 messages from the same source IP, so your client may find itself banned from the network pretty quickly. Both of these problems can be fixed by putting Proxy-Require and Require in. However, that defeats the whole point of this mechanism, to be "backwards compatible" with existing SIP. So, if you do that, may as well use STUN. So, to be clear, I think that this whole idea of something that looks like SIP, but isn't, in the supposed hopes of being "backwards compatible" with existing equipment, is a big, big mistake, and will result in all kinds of unpredicable and really hard to debug problems in the real world. Of course, newer implementations may choose to > optimise the processing for it, so that they can get performance > that is equivalent to STUN, but there is no need to do so for > the feature to work. Implementing the fast-path processing is > therefore purely an implementation issue, not a protocol > compliance issue. Wrong, as I have pointed out. As soon as you make a change that alters MUST-strength processing in clients (as the PING method has), you have introduced interoperability problems. -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 Mon Mar 06 15:01:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGLs2-0005v4-TY; Mon, 06 Mar 2006 14:59:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGLs1-0005sQ-8M for sip@ietf.org; Mon, 06 Mar 2006 14:59:53 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGLrz-0007La-S0 for sip@ietf.org; Mon, 06 Mar 2006 14:59:53 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k26JxiP00957; Mon, 6 Mar 2006 14:59:44 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Date: Mon, 6 Mar 2006 13:59:37 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60ABC55EE@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Thread-Index: AcZBUCKnZgRMiETrTYyRInkNjp33XAAA2d+g From: "Samir Srivastava" To: "Jonathan Rosenberg" , "Michael Procter" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: sip@ietf.org, "Bharrat, Shaun" , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Both STUN CRLF and PING require change on the Proxy. We can have for PING whatever we want.=20 How STUN CLRF is better without changes on the existing Proxy ? To send the response back for STUN CRLF, we need to change the proxies too. But for PING, if proxy is not updated, and it is returning "501 Method Not Implemented" we are okay. And if proxy is good enough, to have a configuration rule saying UnImplmented Methods are not authenticated, then we we are okay too. Though it does not offer Performance benefits of the shunting the SIP parser, but it does offer gradual upgrade. Which is not the case with STUN CRLF.=20 May I ask, how many proxies are there which authenticate unimplemented Methods ?=20 Thx Samir=20 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Monday, March 06, 2006 10:59 AM To: Michael Procter Cc: sip@ietf.org; Bharrat, Shaun; Alan Duric; Dusan Stevanovic Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? inline. Michael Procter wrote: > Bharrat, Shaun wrote: >=20 >>Now that I understand what is actually being done, I guess my question >>is why you would have expected the numbers to be any different? >=20 > [...] >=20 >>If we are "allowed" to skip the SIP processing (i.e. it's not really a >>SIP packet), then I agree that we can make the processing time of a=20 >>PING arbitrarily close to a STUN packet processing. However, if we are >>not, I don't agree that this is a valid comparison of a SIP-based=20 >>keepalive versus a STUN based keepalive. >=20 >=20 > I think the point is that the message has sufficient SIP headers that=20 > it can be parsed and rejected (501) by a stack that doesn't support=20 > the extension. A rejection is an acceptable response to the PING=20 > request, >=20 > So, the PING request is in some sense backwards-compatible with=20 > existing code. Thats my beef with this whole thing. That its "in some sense" backwards compatible, but not really. You are taking something that LOOKS like SIP, but is fundamentally NOT SIP, and sending to a server in the hopes that the right thing happens.=20 However, in the real world, odd things will always happen. Let me give some examples. UAC sends the PING request to its proxy. Proxy doesnt support the method but forwards it on to another proxy, ignorning max-forwards (some elements do this, as they serve as 'fronts' to the real proxy). Packet is lost. Well, you've changed the retransmit rules for PING from normal SIP, and there are no retransmits. So, there is a timeout. We'll have a nice race condition, first of all, since the outbound proxy, having thought this was normal SIP, will generate a 408 at some point, but probably after the UAC gives up. Depends on how you define your new PING protocol transaction timers relative to real sip. Assuming though that the UAC times out first, the UAC will think that its proxy is down, but its not. Seems really bad to me. Here's another funny case. PING goes to a proxy, which doesn't know about PING, but wants to authenticate the request. So, it responds with a 401 and challenges the request. Well, you might say it worked fine - nat binding kept alive. However, many proxies will set off alarms with their intrusion detection systems on repeated 401 messages from the same source IP, so your client may find itself banned from the network pretty quickly. Both of these problems can be fixed by putting Proxy-Require and Require in. However, that defeats the whole point of this mechanism, to be "backwards compatible" with existing SIP. So, if you do that, may as well use STUN. So, to be clear, I think that this whole idea of something that looks like SIP, but isn't, in the supposed hopes of being "backwards compatible" with existing equipment, is a big, big mistake, and will result in all kinds of unpredicable and really hard to debug problems in the real world. Of course, newer implementations may choose to > optimise the processing for it, so that they can get performance that=20 > is equivalent to STUN, but there is no need to do so for the feature=20 > to work. Implementing the fast-path processing is therefore purely an > implementation issue, not a protocol compliance issue. Wrong, as I have pointed out. As soon as you make a change that alters MUST-strength processing in clients (as the PING method has), you have introduced interoperability problems. -Jonathan R. --=20 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 From sip-bounces@ietf.org Mon Mar 06 15:07:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGLxT-0003El-Im; Mon, 06 Mar 2006 15:05:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGLxS-0003Eg-8x for sip@ietf.org; Mon, 06 Mar 2006 15:05:30 -0500 Received: from mail5.audiocodes.com ([212.25.125.21] helo=imss.audiocodes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGLxR-0007VO-D2 for sip@ietf.org; Mon, 06 Mar 2006 15:05:30 -0500 Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan Messaging Security Suite; Mon, 06 Mar 2006 22:07:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Updated connected-identity draft Date: Mon, 6 Mar 2006 22:06:17 +0200 Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD613276D@aclmsg.corp.audiocodes.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Updated connected-identity draft Thread-Index: AcZBPFgAjYEUTeXJTnyo9tuzClQMrAAG3WUQ References: <50B1CBA96870A34799A506B2313F26670841CE66@ntht201e.siemenscomms.co.uk> From: "Ilan Avner" To: "Elwell, John" , "Alexeitsev, D" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 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="===============0076088663==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0076088663== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64159.6DA2C7DD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64159.6DA2C7DD Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi all, I have two questions regarding the identity draft: =20 1.Does the new draft address a feature implemented on the PSTN world = called COLR (Connected number presentation restriction), this feature is = about sending the connected number as a restricted number. the solution for sending restricted numbers as the calling number (in = the first INVITE) is to use the p-asserted header, what about the = connected number? 2.In case the called number had changed after sending 180, as I = understand the UAS should send an UPDATE request with the new number in = the from header. what about the 200 O.K for the INVITE, should the To header also change = to reflect the new called number or should be the same as the To header = sent in the 180? =20 Thanks. =20 Ilan. ________________________________ =EE=E0=FA: Elwell, John [mailto:john.elwell@siemens.com] =F0=F9=EC=E7: =E1 06/03/2006 18:35 =E0=EC: Alexeitsev, D =F2=E5=FA=F7 =EC=E9=E3=E9=F2=E4: sip@ietf.org =F0=E5=F9=E0: RE: [Sip] Updated connected-identity draft Denis, =20 The disadvantage with changing the To header field URI in the INVITE = response is that authentication using the Identity header cannot be = achieved. It may be possible to rely on other means to ensure the = authenticity of this information (e.g., SIPS + transitive trust +use of = TLS on the last hop too). It depends whether there is sufficient = interest from the community in this. =20 John ________________________________ From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 Sent: 06 March 2006 13:57 To: Elwell, John Cc: sip@ietf.org Subject: AW: [Sip] Updated connected-identity draft =09 =09 Hello Jonh =20 Referring to the open issue about the updated To: header in the final = INVITE response: =20 Would it not be possible to have a general solution that would allow = both the change of the To: header URI in the final INVITE response, if = the COLP information is available at that time, and the midcall change = using the UPDATE method? =20 The tests we made with several SIP hard and soft phones show, that the = current implementations would accept the changed To: header URI in the = final INVITE response without any session influence. The changed To: = header URI information would currently not be presented to the user by = the UACs, but this is a user interface issue without protocol impact. =20 In the subsequent requests the UACs would still use the original To: = header URI, so this could be mentioned in the draft to increase the = interoperability with current implementations. =20 Greetings, Denis Alexeistev -----Urspr?ngliche Nachricht----- Von: Elwell, John [mailto:john.elwell@siemens.com]=20 Gesendet: Montag, 6. M?rz 2006 11:50 An: sip@ietf.org Betreff: [Sip] Updated connected-identity draft =09 =09 draft-elwell-sip-connected-identity is now available:=20 = http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-0= 1.txt = =20 Compared with the 00 version, this has changed considerably and is = intended to reflect decisions made in Vancouver. It exploits the ability = to change the From URI during a dialog, so that requests in the reverse = direction can place the source URI in the From header field and the = Identity header can be used to provide authentication, rather having to = introduce new headers. Comments would be appreciated. I would like to = get this adopted as a SIP WG item in Dallas. John=20 ------_=_NextPart_001_01C64159.6DA2C7DD Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= Nachricht=0A= =0A= =0A= =0A=
Hi = all,
=0A=
I have two questions = regarding the =0A= identity draft:
=0A=
 
=0A=
1.Does the new draft address a feature implemented = on the =0A= PSTN world called COLR (Connected number presentation restriction), this = feature =0A= is about sending the connected number as a restricted =0A= number.
=0A=
the = solution for sending =0A= restricted numbers as the calling number (in the first INVITE) is to use = the =0A= p-asserted header, what about the connected number?
=0A=
2.In case = the called =0A= number had changed after sending 180, as I understand the UAS should = send an =0A= UPDATE request with the new number in the from = header.
=0A=
what about = the 200 O.K =0A= for the INVITE, should the To header also change to reflect the new = called =0A= number or should be the same as the To header sent in the =0A= 180?
=0A=
 
=0A=
Thanks.
=0A=
 
=0A=
Ilan.
=0A=

=0A=
=0A=
=0A=
=0A=
=EE=E0=FA: Elwell, = John =0A= [mailto:john.elwell@siemens.com]
=F0=F9=EC=E7: =E1 06/03/2006 =0A= 18:35
=E0=EC: Alexeitsev, D
=F2=E5=FA=F7 = =EC=E9=E3=E9=F2=E4: =0A= sip@ietf.org
=F0=E5=F9=E0: RE: [Sip] Updated = connected-identity =0A= draft

=0A=
=0A=
Denis,
=0A=
 
=0A=
The disadvantage with changing the To header = field URI in =0A= the INVITE response is that authentication using the Identity header = cannot be =0A= achieved. It may be possible to rely on other means to ensure the = authenticity =0A= of this information (e.g., SIPS + transitive trust +use of TLS on the = last hop =0A= too). It depends whether there is sufficient interest from the community = in =0A= this.
=0A=
 
=0A=
John

=0A=
=0A=
=0A=
=0A= From: Alexeitsev, D =0A= [mailto:D.Alexeitsev@t-com.net]
Sent: 06 March 2006 =0A= 13:57
To: Elwell, John
Cc: = sip@ietf.org
Subject: =0A= AW: [Sip] Updated connected-identity draft

=0A=
=0A=
Hello Jonh
=0A=
 
=0A=
Referring to the open issue about the updated To: header in = the final =0A= INVITE response:
=0A=
 
=0A=
Would it not be possible to have a general solution that = would allow =0A= both the change of the To: header URI in the final INVITE response, if = the =0A= COLP information is available at that time, and the midcall change = using the =0A= UPDATE method?
=0A=
 
=0A=
The =0A= tests we made with several SIP hard and soft phones show, that the = current =0A= implementations would accept the changed To: header URI in the final = INVITE =0A= response without any session influence. The changed To: header URI = information =0A= would currently not be presented to the user by the UACs, but this is = a user =0A= interface issue without protocol impact.
=0A=
 
=0A=
In =0A= the subsequent requests the UACs would still use the original To: = header URI, =0A= so this could be mentioned in the draft to increase the = interoperability =0A= with current implementations.
=0A=
 
=0A=
Greetings,
=0A=
Denis Alexeistev
=0A=
-----Ursprüngliche = Nachricht-----
Von: =0A= Elwell, John [mailto:john.elwell@siemens.com]
Gesendet: = Montag, 6. =0A= März 2006 11:50
An: sip@ietf.org
Betreff: = [Sip] Updated =0A= connected-identity draft

=0A=
=0A=

draft-elwell-sip-connected-identity = is now =0A= available:
http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-i= dentity-01.txt =0A=

=0A=

Compared with the 00 version, this = has changed =0A= considerably and is intended to reflect decisions made in Vancouver. = It =0A= exploits the ability to change the From URI during a dialog, so that =0A= requests in the reverse direction can place the source URI in the = >From =0A= header field and the Identity header can be used to provide = authentication, =0A= rather having to introduce new headers. Comments would be = appreciated. I =0A= would like to get this adopted as a SIP WG item in Dallas.

=0A=

John =0A=

=0A= =0A= ------_=_NextPart_001_01C64159.6DA2C7DD-- --===============0076088663== 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 --===============0076088663==-- From sip-bounces@ietf.org Mon Mar 06 15:13:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGM3B-0000Pm-8Q; Mon, 06 Mar 2006 15:11:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGM3A-0000PM-EJ; Mon, 06 Mar 2006 15:11:24 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGM3A-000804-3O; Mon, 06 Mar 2006 15:11:24 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k26KBJ0e010722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 20:11:20 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGM35-0007PI-PX; Mon, 06 Mar 2006 15:11:19 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 06 Mar 2006 15:11:19 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: sip mailing list , sip chair , Internet Architecture Board , sip chair , RFC Editor Subject: [Sip] Protocol Action: 'Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 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 IESG has approved the following document: - 'Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-target-dialog-03.txt Technical Summary This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. SIP defines the concept of a dialog as a persistent relationship between a pair a of user agents (UA). When a UA receives a request that creates a dialog, it needs decide whether to authorize that request. For some requests, authorization is a function of the identity of the sender, the request method, and so on. However, many situations have been identified, in which a user agent's authorization decision depends on whether the sender of the request is currently in a dialog with that user agent, or whehter the sender of the request is aware of a dialog the user agent has with another entity. One such example is call transfer, accomplished through REFER. Working Group Summary The working group supported the advancement of this specification. Protocol Quality Allison Mankin reviewed this document for the IESG. Dean Willis is the WG Chair shepherd. Notes to RFC Editor: [all of these changes reflect the fact that the GRUU is not essential to target-dialog] Section 1, Introduction, Para 3 OLD: Instead, a better approach is for user agent A to send the REFER request to user agent B outside of the dialog using its Globally Routable User Agent URI (GRUU) [11]. In that case, a means is needed for user agent B to authorize the REFER. NEW: Instead, a better approach is for user agent A to send the REFER request to user agent B outside of the dialog. In that case, a means is needed for user agent B to authorize the REFER. Section 2, Overview of Operation, Para 1 OLD: This 200 OK includes a Supported header field indicating support for both the GRUU specification (through the presence of the gruu option tag) and this specification (through the presence of the tdialog option tag). NEW: This 200 OK includes a Supported header field indicating support for this specification (through the presence of the tdialog option tag). Para #2: OLD: So, the entity acts as a user agent and sends the request to user agent B. This request is addressed to the GRUU of user agent B, which server A learned from inspecting the Contact header field in the 200 OK of the INVITE request. This GRUU is a URI that can be used by any element on the Internet, such as server A, to reach the specific user agent instance that generated that 200 OK to the INVITE. NEW: So, the entity acts as a user agent and sends the request to user agent B. This request is addressed to the URI of user agent B, which server A learned from inspecting the Contact header field in the 200 OK of the INVITE request. If this URI has the GRUU [11] property (it be used by any element on the Internet, such as server A, to reach the specific user agent instance that generated that 200 OK to the INVITE) then the mechanism will work across NAT boundaries. Section 10, Example Call Flow, Para 1: OLD: To do that, it sends a REFER request to A's GRUU. The flow for this is shown in Figure 5. NEW: To do that, it sends a REFER request to A's URI. The flow for this is shown in Figure 5. Example, Under Figure 5, Legend: "First the caller sends an INVITE, as shown in message 1": OLD: Supported: gruu, tdialog NEW: Supported: tdialog ------ Add the following at the end of Section 1: Section 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [xx]. - Add [xx], a normative reference to RFC 2119. ------- Section 8, Security Considerations OLD: The second condition is that the dialog identifiers be cryptographically random that they cannot be guessed. RFC 3261 requires global uniquess for the Call-ID and 32 bits of cryptographic randomness for each tag (there are two tags for a dialog). Given the short duration over which a typical dialog exists (perhaps as long as a day), this amount of randomness appears adequate to prevent guessing attacks. However, its important to note that this specification truly requires cryptographic randomness, as opposed to just pseudorandom identifiers. Pseudorandom identifiers reduce the probability of collision, but because they are guessable, NEW: The second condition is that the dialog identifiers be sufficiently cryptographically random that they cannot be guessed. RFC 3261 requires global uniqueness for the Call-ID and 32 bits of cryptographic randomness for each tag (there are two tags for a dialog). Given the short duration over which a typical dialog exists (perhaps as long as a day), this amount of randomness appears adequate to prevent guessing attacks. However, it's important to note, that this specification requires true cryptographic randomness as set forth in RFC 4086 [yy]. Weaker pseudorandom identifiers reduce the probability of collision, but because they are guessable, - Add [yy], an Informative reference to RFC 4086 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 06 15:28:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMHf-0004RW-3W; Mon, 06 Mar 2006 15:26:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMHe-0004RR-CM for sip@ietf.org; Mon, 06 Mar 2006 15:26:22 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMHe-0000Cn-1T for sip@ietf.org; Mon, 06 Mar 2006 15:26:22 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k26KQFX11201; Mon, 6 Mar 2006 15:26:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Comment on draft-fwmiller-sip-00 Date: Mon, 6 Mar 2006 14:25:47 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60ABC5675@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Comment on draft-fwmiller-sip-00 Thread-Index: AcZBMir+i7V4OHyYRFKhwVkd+PJGqwAKIh9A From: "Samir Srivastava" To: , "Cullen Jennings" , X-Spam-Score: 0.1 (/) 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 Additionally, With OPTIONS you can have Require and Proxy-Require. Which is not allowed in PING. So Proxies doesn't need to parse complete PING message. FM, Pl add the implementation guidelines with respect to Optimization offered. One can find "PING" string at the start of transport payload with standard compliant clients. Thx Samir -----Original Message----- From: fwmiller@cornfed.com [mailto:fwmiller@cornfed.com]=20 Sent: Monday, March 06, 2006 7:25 AM To: Cullen Jennings; sip@ietf.org; fwmiller@cornfed.com Subject: [Sip] RE: Comment on draft-fwmiller-sip-00 I would point you at the most recent version, -01. The new version does away with the retransmission requirements. The UAC sends a single PING to a UAS. If a response is not received within a timeout, the application is notified and can decide for itself whether to retransmit. This is definitely different than OPTIONS. This makes it look something like an ICMP ping. Other than that tho, there is a lot of similarity. I has also been mentioned that since there is explicitly no body allowed and the attempt to minimize the headers, the potential for optimizations in an implementation is greater. FM P.S. Looking at it again, I mentioned an expiration interval before reporting that the ping was not responded to but did not actually specify a duration :( Suggestions? I'm thinking like 500 ms? ------------------------------------------------ On Sun, 05 Mar 2006 15:47:57 -0500, Cullen Jennings wrote: >=20 > I don't really see what this PING method does that OPTIONS does not?=20 > If the answer is that this can somehow be optimized in ways that=20 > OPTIONS can't, then it is missing all the text to explain that. >=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 Mon Mar 06 15:40:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMTQ-0006tR-J8; Mon, 06 Mar 2006 15:38:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMTO-0006tG-N0; Mon, 06 Mar 2006 15:38:30 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMTO-0000aq-EF; Mon, 06 Mar 2006 15:38:30 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k26KcQ0e010980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 20:38:26 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGMTK-0003P9-En; Mon, 06 Mar 2006 15:38:26 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 06 Mar 2006 15:38:26 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sip mailing list , sip chair , Internet Architecture Board , sip chair , RFC Editor Subject: [Sip] Protocol Action: 'Conveying Feature Tags with Session Initiation Protocol REFER Method' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 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 IESG has approved the following document: - 'Conveying Feature Tags with Session Initiation Protocol REFER Method ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-feature-param-01.txt Technical Summary The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. Working Group Summary This specification is the result of several months of discussion in the SIP working group. The key issue resolved was around the scope of capabilities to be expressed, with agreement on the capabilities expression of RFC 3840 developing during a break-out session at IETF 63. This compromise position received broad support. Protocol Quality The specification was reviewed for quality by the SIP working group and by SIP Chair Dean Willis. It includes only a very small extension to the REFER method of RFC 3515. Dean is the working group chair shepherd. Allison Mankin is the Responsible Area Director. Note to RFC Editor [provide a full abstract] Abstract OLD: This document extends the REFER method, defined in RFC 3515, to convey feature parameters defined in RFC 3840. NEW: The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. Section 3, Definitions: OLD: Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param) is extended to: Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI refer-param) NEW: Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *(SEMI generic-param) is extended to: Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *(SEMI refer-param) [eliminate the spaces after the *] -------- Also in Section 3: OLD: Note that if any URI parameters are present, the entire URI must be enclosed in "<" and ">". If no "<" and ">" are present, all parameters after the URI are header parameters, not URI parameters. NEW: Note that if any URI parameters are present, the entire URI must be enclosed in "<" and ">". If the "<" and ">" are not present, all parameters after the URI are header parameters, not URI parameters. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 06 15:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMUF-00083i-Dm; Mon, 06 Mar 2006 15:39:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMUD-0007yW-TJ for sip@ietf.org; Mon, 06 Mar 2006 15:39:21 -0500 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 1FGMUB-0000f0-8R for sip@ietf.org; Mon, 06 Mar 2006 15:39:21 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2006 12:39:18 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="412878915:sNHT37798864" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k26KdE7T029122; Mon, 6 Mar 2006 12:39:15 -0800 (PST) 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.211); Mon, 6 Mar 2006 15:39:14 -0500 Received: from [192.168.1.101] ([10.86.240.173]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 15:39:14 -0500 Message-ID: <440C9DF1.8080401@cisco.com> Date: Mon, 06 Mar 2006 15:39:13 -0500 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: Samir Srivastava Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? References: <62B9B0847CC47543B6B3B5E26BD268E60ABC55EE@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60ABC55EE@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2006 20:39:14.0339 (UTC) FILETIME=[07FCFF30:01C6415E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: sip@ietf.org, "Bharrat, Shaun" , Michael Procter , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava wrote: > Both STUN CRLF and PING require change on the Proxy. We can have for > PING whatever we want. > How STUN CLRF is better without changes on the existing Proxy ? The case that one needs to be concerned about is when the proxy doesn't support this mechanism, not when it does. > > To send the response back for STUN CRLF, we need to change the proxies > too. But for PING, if proxy is not updated, and it is returning "501 > Method Not Implemented" we are okay. Well, my point is, that is not always going to be the case. Firstly, proxies are not supposed to have to know about new methods. Quoting RFC3261: > This is a model of proxy behavior, not of software. An > implementation is free to take any approach that replicates the > external behavior this model defines. > > For all new requests, including any with unknown methods, an element > intending to proxy the request MUST: > > 1. Validate the request (Section 16.3) > > 2. Preprocess routing information (Section 16.4) > > 3. Determine target(s) for the request (Section 16.5) > > +--------------------+ > | | +---+ > | | | C | > | | | T | > | | +---+ > +---+ | Proxy | +---+ CT = Client Transaction > | S | | "Higher" Layer | | C | > | T | | | | T | ST = Server Transaction > +---+ | | +---+ > | | +---+ > | | | C | > | | | T | > | | +---+ > +--------------------+ > > Figure 3: Stateful Proxy Model > > > > > > > Rosenberg, et. al. Standards Track [Page 93] > > RFC 3261 SIP: Session Initiation Protocol June 2002 > > > 4. Forward the request to each target (Section 16.6) > > 5. Process all responses (Section 16.7) Note the bit about unknown methods. So, a normal RFC3261 compliant proxy WILL NOT reject a PING request with a 501. You can force it to reject any request, including PING, by setting Max-Forwards to zero. But the point is, there is lots of other processing in a standard proxy that is going to interfere with your assumptions in this PING method. > And if proxy is good > enough, to have a configuration rule saying UnImplmented Methods are not > authenticated, then we > we are okay too. Normally all requests are authenticated. It is a security problem ot not authenticate a request just because its method is unknown. Imagine a new method NOT-INVITE, which carries SDP around, used to set up calls. Works much like invite, but I changed the method name. I can get free service from my proxy network if its not authenticated. > Though it does not offer Performance benefits of the > shunting the SIP parser, but it does offer gradual upgrade. Which is not > the case with STUN CRLF. No. This PING is a recipe for huge operational problems unless the proxies all support it. > > May I ask, how many proxies are there which authenticate unimplemented > Methods ? Unimplemented? Careful here - we're talking about unknown methods. Proxies arent supposed to know about methods except for INVITE, CANCEL ACK adn then everything else. You make it sounds like its a bug to authenticate unknown methods (mine does, btw). Its not. But let me pick another bad thing that can happen. Lets say our poor proxy is overloaded, probably from all of these PING requests. So, to quench traffic, it sends a 503 with a Retry-After, under the assumption that a compliant UAC will properly back off. But, the UAC doesn't (since UAC processing violates RFC 3261 for this method). The network continues to be overloaded with no recourse. Again, the source IP is likely to be blacklisted for non-compliance. The flip side of this problem is a client which sends a request called PING to a server, not realizing that a spec has been produced which redefines SIP processing for tihs specific method. As such, this client is expecting normal SIP processing for this request. It hits a server which supports this "extension". This is a real issue, btw - I am aware of implementations which use the method PING. Lets say the client is using this ping for a traceroute facility. So, it sends the request with a non-zero Max-Forwards. This hits a proxy which immediately rejects it since it supports the ping "extension". Now the client is going to get incorrect information from its traceroute processing. Let us not forget that the stun mecahnism can still have a fallback to non-stun operation if the server doesnt support it. Stun messages are sent to the sip port only when the flag is present in the SIP URI indicating that the server can do the demux. We do EXACTLY this same thing with sigcomp, btw. So, if a client which supports sip outbound, has a URI for its outbound proxy which doesnt have this flag, it can resort to plain old OPTIONS with Max-Forwards: 0. No different than what happens with PING when the server doesn't support it, except we don't have the interop problems that PING will bring. -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 Mon Mar 06 15:44:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMXe-00045Y-Ku; Mon, 06 Mar 2006 15:42:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMXd-00045T-7a for sip@ietf.org; Mon, 06 Mar 2006 15:42:53 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMXc-0000vQ-Nl for sip@ietf.org; Mon, 06 Mar 2006 15:42:53 -0500 Received: (qmail 13152 invoked by uid 0); 6 Mar 2006 20:42:48 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 Mar 2006 20:42:48 -0000 Message-ID: <005601c6415e$83c5d6f0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "Tan, Ya-Ching" References: <440C81C6.6000601@cisco.com> Subject: Re: AW: [Sip] draft ietf-sip-target-dialog provisionally approvedby IESG Date: Mon, 6 Mar 2006 21:42:41 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Jonathan, A minor bug in http://www3.ietf.org/internet-drafts/draft-ietf-sip-target-dialog-03.txt: the ABNF rule for Call-ID in RFC3261 is spelled "callid" (so without the '-' character) For sake of completeness, the text in section 7 should state that 'callid', 'token' and 'generic-param' refer to the RFC3261 definitions Regards, Jeroen PS It's good to treat callid separately, also because it may contain characters that are not allowed in parameter values. So you'd have to quote, escape, etc ----- Original Message ----- From: "Jonathan Rosenberg" To: "Tan, Ya-Ching" Cc: "sip ietf" Sent: Monday, March 06, 2006 7:39 PM Subject: Re: AW: [Sip] draft ietf-sip-target-dialog provisionally approvedby IESG > > > Tan, Ya-Ching wrote: > >> >> Some late comments : >> >> - The texts state that the dialog identifiers for the Target-Dialog >> header MUST contain the "call-id", "local-tag" and "remote-tag". I >> wonder why the header is not defined to treat all these mandatory >> components equally (eg. Target-Dialog : >> call-id=fa77as7dad8-sd98ajzz@host.example.com, local-tag=kkaz, >> remote-tag=6544). > > Either way would work. Generally, header fields have values and then > parameters separated by semicolons. If you did what you propose above, > you'd have to make up something to put in the value, for example * or > something. May as well put call-id in there. > > In any case, as you know the draft has been approved already so this kind > of change couldn't really be made at this point. Bugs and fixes like that > are OK, but a design change wouldn't be appropriate. > > The current BNF definition implies that the >> "local-tag" and "remote-tag" are optional parameters of the header, >> which is misleading. > > BNF cannot express all constraints. Here, we want all parameters to be > present, but with arbitrary order. That is VERY hard to write in a bnf, > and lends no clarity if you do it. The spec is quite explicit that all > must be present. We have had this situation in many specifications, and > always we use BNF to help specify the grammar of the messages, not the > full set of constraints on the protocol. > > >> >> - Figure 4 shows that a proxy (acting as a proxy) can add ("a") or >> remove ("r") a Target-Dialog header. Shouldn't it be left blank there >> (like for the In-Reply-To header in RFC 3261) ? > > I think you're probably right, this is a bug. This we can correct during > auth48. I'll make a note. > >> >> - In the example on on Page 12, the REFER is shown to contain an >> Event header. REFERs normally have no Event header, as this >> subscription is implicit. > > Right, another bug. Will fix during auth48. > > Thanks for the 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 06 16:03:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMq2-0000lJ-5W; Mon, 06 Mar 2006 16:01:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMfN-0004Xt-Ui for sip@ietf.org; Mon, 06 Mar 2006 15:50:53 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMfN-0001ac-5E for sip@ietf.org; Mon, 06 Mar 2006 15:50:53 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 06 Mar 2006 12:50:52 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k26KooH7000575; Mon, 6 Mar 2006 12:50:52 -0800 (PST) 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.211); Mon, 6 Mar 2006 15:50:33 -0500 Received: from [192.168.1.101] ([10.86.240.173]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 15:50:33 -0500 Message-ID: <440CA098.3000108@cisco.com> Date: Mon, 06 Mar 2006 15:50:32 -0500 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: AW: [Sip] draft ietf-sip-target-dialog provisionally approvedby IESG References: <440C81C6.6000601@cisco.com> <005601c6415e$83c5d6f0$31713b51@BEMBUSTER> In-Reply-To: <005601c6415e$83c5d6f0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2006 20:50:33.0499 (UTC) FILETIME=[9CCC96B0:01C6415F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 Thanks. I'll handle these too. Would've been nice to get these BEFORE the document was approved though.... -Jonathan R. Jeroen van Bemmel wrote: > Jonathan, > > A minor bug in > http://www3.ietf.org/internet-drafts/draft-ietf-sip-target-dialog-03.txt: > the ABNF rule for Call-ID in RFC3261 is spelled "callid" (so without the > '-' character) > > For sake of completeness, the text in section 7 should state that > 'callid', 'token' and 'generic-param' refer to the RFC3261 definitions > > Regards, > > Jeroen > > PS It's good to treat callid separately, also because it may contain > characters that are not allowed in parameter values. So you'd have to > quote, escape, etc > > ----- Original Message ----- From: "Jonathan Rosenberg" > To: "Tan, Ya-Ching" > Cc: "sip ietf" > Sent: Monday, March 06, 2006 7:39 PM > Subject: Re: AW: [Sip] draft ietf-sip-target-dialog provisionally > approvedby IESG > > >> >> >> Tan, Ya-Ching wrote: >> >>> >>> Some late comments : >>> >>> - The texts state that the dialog identifiers for the Target-Dialog >>> header MUST contain the "call-id", "local-tag" and "remote-tag". I >>> wonder why the header is not defined to treat all these mandatory >>> components equally (eg. Target-Dialog : >>> call-id=fa77as7dad8-sd98ajzz@host.example.com, local-tag=kkaz, >>> remote-tag=6544). >> >> >> Either way would work. Generally, header fields have values and then >> parameters separated by semicolons. If you did what you propose above, >> you'd have to make up something to put in the value, for example * or >> something. May as well put call-id in there. >> >> In any case, as you know the draft has been approved already so this >> kind of change couldn't really be made at this point. Bugs and fixes >> like that are OK, but a design change wouldn't be appropriate. >> >> The current BNF definition implies that the >> >>> "local-tag" and "remote-tag" are optional parameters of the header, >>> which is misleading. >> >> >> BNF cannot express all constraints. Here, we want all parameters to be >> present, but with arbitrary order. That is VERY hard to write in a >> bnf, and lends no clarity if you do it. The spec is quite explicit >> that all must be present. We have had this situation in many >> specifications, and always we use BNF to help specify the grammar of >> the messages, not the full set of constraints on the protocol. >> >> >>> >>> - Figure 4 shows that a proxy (acting as a proxy) can add ("a") or >>> remove ("r") a Target-Dialog header. Shouldn't it be left blank there >>> (like for the In-Reply-To header in RFC 3261) ? >> >> >> I think you're probably right, this is a bug. This we can correct >> during auth48. I'll make a note. >> >>> >>> - In the example on on Page 12, the REFER is shown to contain an >>> Event header. REFERs normally have no Event header, as this >>> subscription is implicit. >> >> >> Right, another bug. Will fix during auth48. >> >> Thanks for the 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 > > -- 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 Mon Mar 06 16:20:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGN60-0005X7-60; Mon, 06 Mar 2006 16:18:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGN5y-0005Uw-Nj for sip@ietf.org; Mon, 06 Mar 2006 16:18:22 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGN5y-0006oi-DO for sip@ietf.org; Mon, 06 Mar 2006 16:18:22 -0500 Received: by tutpro.com (Postfix, from userid 65534) id B5544140406; Mon, 6 Mar 2006 23:18:20 +0200 (EET) Received: from rautu (unknown [202.73.194.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 6073C13F977; Mon, 6 Mar 2006 23:18:14 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 577E4F027C; Mon, 6 Mar 2006 23:18:22 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17420.42782.282306.681194@rautu.tutpro.com> Date: Mon, 6 Mar 2006 23:18:22 +0200 From: Juha Heinanen To: "Samir Srivastava" Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60ABC55EE@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60ABC55EE@zrc2hxm2.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sip@ietf.org, Michael Procter , "Bharrat, Shaun" , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava writes: > May I ask, how many proxies are there which authenticate unimplemented > Methods ? proxies' job is to route requests, not interpret them. -- 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 Mar 06 16:31:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNGb-0003E6-0M; Mon, 06 Mar 2006 16:29:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNGX-0003Dc-Ky for sip@ietf.org; Mon, 06 Mar 2006 16:29:18 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNGU-0007ia-AH for sip@ietf.org; Mon, 06 Mar 2006 16:29:17 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k26LOtd04069; Mon, 6 Mar 2006 16:24:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Date: Mon, 6 Mar 2006 15:29:06 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60ABC57EA@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Thread-Index: AcZBY4pCaBtyui85TBa/8L5DhHGBdQAAMZ8A From: "Samir Srivastava" To: "Juha Heinanen" X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, Michael Procter , "Bharrat, Shaun" , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 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's my mistake regarding the term. Gernally, Edge Proxies are implemented as B2BUA and they interpet requests.=20 Thx Samir -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: Monday, March 06, 2006 1:18 PM To: Srivastava, Samir [SC100:8826:EXCH] Cc: Jonathan Rosenberg; Michael Procter; sip@ietf.org; Bharrat, Shaun; Alan Duric; Dusan Stevanovic Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN request processing fasterthan a SIP PING requestprocessing? Samir Srivastava writes: > May I ask, how many proxies are there which authenticate unimplemented > Methods ?=20 proxies' job is to route requests, not interpret them. -- 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 Mar 06 17:25:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO6o-0005gM-Dn; Mon, 06 Mar 2006 17:23:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO6m-0005g5-EW for sip@ietf.org; Mon, 06 Mar 2006 17:23:16 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGO6l-0003AN-4w for sip@ietf.org; Mon, 06 Mar 2006 17:23:16 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 06 Mar 2006 14:23:15 -0800 X-IronPort-AV: i="4.02,169,1139212800"; d="scan'208"; a="259918822:sNHT33854976" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k26MNCYi001590; Mon, 6 Mar 2006 14:23:13 -0800 (PST) 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.211); Mon, 6 Mar 2006 17:23:12 -0500 Received: from [192.168.1.101] ([10.86.240.173]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 17:23:11 -0500 Message-ID: <440CB64F.5010608@cisco.com> Date: Mon, 06 Mar 2006 17:23:11 -0500 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: Samir Srivastava Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? References: <62B9B0847CC47543B6B3B5E26BD268E60ABC57EA@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60ABC57EA@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2006 22:23:11.0959 (UTC) FILETIME=[8DE64670:01C6416C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, Juha Heinanen , Michael Procter , Alan Duric , "Bharrat, Shaun" , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So are you saying that this mechanism will only work for b2bua? I think that is a real problem. -Jonathan R. Samir Srivastava wrote: > It's my mistake regarding the term. > > Gernally, Edge Proxies are implemented as B2BUA and they interpet > requests. > > Thx > Samir > > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Monday, March 06, 2006 1:18 PM > To: Srivastava, Samir [SC100:8826:EXCH] > Cc: Jonathan Rosenberg; Michael Procter; sip@ietf.org; Bharrat, Shaun; > Alan Duric; Dusan Stevanovic > Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN request processing > fasterthan a SIP PING requestprocessing? > > Samir Srivastava writes: > > > May I ask, how many proxies are there which authenticate > unimplemented > Methods ? > > proxies' job is to route requests, not interpret them. > > -- juha > -- 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 Mon Mar 06 17:25:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO7O-0006NO-P8; Mon, 06 Mar 2006 17:23:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO7N-0006N8-UE for sip@ietf.org; Mon, 06 Mar 2006 17:23:53 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGO7M-0003Gv-HQ for sip@ietf.org; Mon, 06 Mar 2006 17:23:53 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EBFA1586; Mon, 6 Mar 2006 23:23:51 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 23:23:51 +0100 Received: from [136.225.183.93] ([136.225.183.93]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 23:23:47 +0100 From: "Christer Holmberg" To: "Paul Kyzivat" Date: Tue, 7 Mar 2006 00:18:57 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 06 Mar 2006 22:23:50.0792 (UTC) FILETIME=[A50BB880:01C6416C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: IETF SIP List Subject: [Sip] Re: Dialog usage: Forking impacts X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, It is true that both 2 and 3 can establish early dialogs with 1. The issue, = as I said in another mail, is that when 200 OK is received UA_1 may = terminate all other early dialogs - not only specific dialoge usages. The problem is of course that RFC3261 does not talk about dialog usages - = only "full" dialoges. 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 Mon Mar 06 17:25:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO7Y-0006kV-LA; Mon, 06 Mar 2006 17:24:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO7W-0006fi-96 for sip@ietf.org; Mon, 06 Mar 2006 17:24:02 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGO7U-0003Hw-UV for sip@ietf.org; Mon, 06 Mar 2006 17:24:02 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 299FACB5; Mon, 6 Mar 2006 23:24:00 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 23:23:59 +0100 Received: from [136.225.183.93] ([136.225.183.93]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 23:23:56 +0100 From: "Christer Holmberg" To: "Robert Sparks" Date: Tue, 7 Mar 2006 00:19:06 +0200 Message-ID: <1nq644YzRG1g.WkvLlkC3@se-smtp.ericsson.se> X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 06 Mar 2006 22:23:59.0480 (UTC) FILETIME=[AA396780:01C6416C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IETF SIP List , Paul Kyzivat Subject: [Sip] Re: Dialog usage: Forking impacts X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Robert, It is true that 1-2 has two dialog usages, and the CANCEL should cause 2 to = terminate one of them (but keep the subscribe dialog alive). The problem is that 1 may, when receiving 200 OK from 3, terminate the = dialog - not only a specific dialog usage - with 2. 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 Mon Mar 06 17:25:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO7f-0006wr-Pa; Mon, 06 Mar 2006 17:24:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO7d-0006tc-NH for sip@ietf.org; Mon, 06 Mar 2006 17:24:09 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGO7d-0003J8-EF for sip@ietf.org; Mon, 06 Mar 2006 17:24:09 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D4E53CA4; Mon, 6 Mar 2006 23:24:08 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 23:24:08 +0100 Received: from [136.225.183.93] ([136.225.183.93]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 23:24:05 +0100 From: "Christer Holmberg" To: "Juha Heinanen" , "David Schwartz" Subject: RE: [Sip] OUTBOUND: Direction of keep-alive requests Date: Tue, 7 Mar 2006 00:19:15 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 06 Mar 2006 22:24:08.0167 (UTC) FILETIME=[AF66EF70:01C6416C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, My proposal was that the network would send a SIP request towards the UA, = and the response sent back by the UA would act as the "ping". 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 Mon Mar 06 17:26:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO8E-0007oO-9Q; Mon, 06 Mar 2006 17:24:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO8C-0007mN-85 for sip@ietf.org; Mon, 06 Mar 2006 17:24:44 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNNq-0008Rt-TN for sip@ietf.org; Mon, 06 Mar 2006 16:36:50 -0500 Received: from mail.infointeractive.com ([207.231.225.15] helo=smtp.infointeractive.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGMeo-0002w1-U4 for sip@ietf.org; Mon, 06 Mar 2006 15:50:32 -0500 Received: from eng.infointeractive.com ([10.142.0.50]:44524 "EHLO eng.infointeractive.com") by mail.infointeractive.com with ESMTP id S824469AbWCFUuO (ORCPT ); Mon, 6 Mar 2006 16:50:14 -0400 Received: from localhost (user: 'benoit', uid#6008) by eng.infointeractive.com id <214984-3320>; Mon, 6 Mar 2006 16:50:07 -0400 Date: Mon, 6 Mar 2006 16:50:07 -0400 From: David Benoit To: sip@ietf.org Message-ID: <20060306205006.GA25030@infointeractive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: -2.6 (--) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [Sip] Determining if a call _can_ function X-BeenThere: sip@ietf.org X-Mailman-Version: 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, When placing a SIP call from certain network locations, your ability to receive incoming messages may be limited. One major problem is determining if a call can actually function from one endpoint to another. Consider the following scenario: - Alice is a subscriber to a reasonable ISP that doesn't allow inbound TCP connections to "random things" - Alice wishes to call Bob. Pretty simple. So, obviously Alice's UAC should choose UDP to initiate the call and everything will work. However, there is a gotcha. If Alice has a UAC that supports a LOT of codecs, or requires a large nonce in the authentication header, etc., Section 18.1.1 or RFC 3261 comes into play. So, if Alice's UAC _has_ to use TCP or TLS (if Bob was at "sips: ...") then there is a problem. This is what will happen. The INVITE will be sent to Bob's UAS, the response messages will be, properly, sent back to Alice's UAC on the TCP connection on which the INVITE was received, and Alice's UAC will send the ACK (as a new transaction) directly to Bob's UAC (possibly skipping any proxies involved with the initial INVITE). Now, if Bob's UAS/UAC implements RFC 4028 timers, then when Bob's UAS/UAC negotiates itself as the refresher it can't send a new transaction to Alice's UAC because a TCP connection can't be made to Alice's machine. The refresh will fail and the call will be killed at Bob's end. Even if neither implements timers, or Alice's UAC is the refresher, then when Bob wishes to hangup, the BYE message can't be sent to Alice's UAC for the same reasons. This situation can be detected by Bob's UAS/UAC while processing the INVITE. It can attempt to send a transaction to Alice's UAC and if any response to that transaction is received, the call should be able to continue without issue. Alice's UAC Bob's UAS/UAC | | |----- INVITE ---->| |<------ 100 ------| | X<--- PING ----| | ECONNREFUSED ->| |<------ 6XX ------| |------- ACK ----->| And here's one if Alice's ISP removed that restriction: Alice's UAC Bob's UAS/UAC | | |----- INVITE ---->| |<------ 100 ------| |<----- PING ------| |---- [2456]xx --->| |<------ 200 ------| |------- ACK ----->| In this case, Bob's UAS/UAC knows that it will be able (unless the rules are changed mid-session) that proper message flow can occur. The introduction of a new 6xx code to indicate that the Contact information presented in the INVITE is unusable would allow Bob's UAS to tell Alice's UAC about this condition. This would fit with the intended use of the PING method in determining the validity of the signaling path. This does impose extra cost on all TCP calls. Is there an alternative way to detect this scenario? David -- David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 "Complex problems have simple, neat and wrong solutions" - H. L. Menken _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 06 17:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO9j-0000wE-Dg; Mon, 06 Mar 2006 17:26:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO9h-0000v1-S2 for sip@ietf.org; Mon, 06 Mar 2006 17:26:17 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNNY-0008PN-9n for sip@ietf.org; Mon, 06 Mar 2006 16:36:32 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGMqa-0003gc-8k for sip@ietf.org; Mon, 06 Mar 2006 16:02:30 -0500 Received: by tutpro.com (Postfix, from userid 65534) id BE713140406; Mon, 6 Mar 2006 23:02:25 +0200 (EET) Received: from rautu (unknown [202.73.194.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id BB4D7140401; Mon, 6 Mar 2006 23:02:17 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 115A0F027C; Mon, 6 Mar 2006 23:02:24 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17420.41824.14364.710766@rautu.tutpro.com> Date: Mon, 6 Mar 2006 23:02:24 +0200 From: Juha Heinanen To: "David Schwartz" Subject: RE: [Sip] OUTBOUND: Direction of keep-alive requests In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A606551CE3FE@isr-jlm-mail.Kayote.com> References: <1DDB0D3CC4E7F14FAE946361C0A606551CE3FE@isr-jlm-mail.Kayote.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: -2.6 (--) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: IETF SIP List , Christer Holmberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Your comment that you have not seen this limitation in NAT's only = strengthens Christers claim that a network based keep alive should be = considered as well. it is the only approach that is needed. i thought christers was proposing to do pinging from the UA. -- 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 Mar 06 17:48:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOTU-0000OF-Et; Mon, 06 Mar 2006 17:46:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOTT-0000Nq-1O for sip@ietf.org; Mon, 06 Mar 2006 17:46:43 -0500 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 1FGOTR-0004js-MS for sip@ietf.org; Mon, 06 Mar 2006 17:46:43 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2006 14:46:41 -0800 X-IronPort-AV: i="4.02,169,1139212800"; d="scan'208"; a="412913489:sNHT33816484" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k26Mkb7T024489; Mon, 6 Mar 2006 14:46:41 -0800 (PST) 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.211); Mon, 6 Mar 2006 17:46:37 -0500 Received: from [192.168.1.101] ([10.86.240.173]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 17:46:37 -0500 Message-ID: <440CBBCC.3000804@cisco.com> Date: Mon, 06 Mar 2006 17:46:36 -0500 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: David Benoit Subject: Re: [Sip] Determining if a call _can_ function References: <20060306205006.GA25030@infointeractive.com> In-Reply-To: <20060306205006.GA25030@infointeractive.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2006 22:46:37.0183 (UTC) FILETIME=[D37A70F0:01C6416F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 This problem is solved with draft-ietf-sip-outbound, which ensures that the outbound connect initiated by a client towards its proxy is used for all incoming messages, both new calls and mid-dialog requests in the reverse direction. -Jonathan R> David Benoit wrote: > Hi, > > When placing a SIP call from certain network locations, your ability to > receive incoming messages may be limited. One major problem is > determining if a call can actually function from one endpoint to another. > Consider the following scenario: > > - Alice is a subscriber to a reasonable ISP that doesn't allow inbound TCP > connections to "random things" > - Alice wishes to call Bob. > > Pretty simple. > > So, obviously Alice's UAC should choose UDP to initiate the call and > everything will work. However, there is a gotcha. If Alice has a UAC > that supports a LOT of codecs, or requires a large nonce in the > authentication header, etc., Section 18.1.1 or RFC 3261 comes into play. > So, if Alice's UAC _has_ to use TCP or TLS (if Bob was at "sips: ...") > then there is a problem. > > This is what will happen. The INVITE will be sent to Bob's UAS, the > response messages will be, properly, sent back to Alice's UAC on the TCP > connection on which the INVITE was received, and Alice's UAC will send the > ACK (as a new transaction) directly to Bob's UAC (possibly skipping any > proxies involved with the initial INVITE). > > Now, if Bob's UAS/UAC implements RFC 4028 timers, then when Bob's UAS/UAC > negotiates itself as the refresher it can't send a new transaction to > Alice's UAC because a TCP connection can't be made to Alice's machine. > The refresh will fail and the call will be killed at Bob's end. > > Even if neither implements timers, or Alice's UAC is the refresher, then > when Bob wishes to hangup, the BYE message can't be sent to Alice's UAC > for the same reasons. > > This situation can be detected by Bob's UAS/UAC while processing the > INVITE. It can attempt to send a transaction to Alice's UAC and if any > response to that transaction is received, the call should be able to > continue without issue. > > Alice's UAC Bob's UAS/UAC > | | > |----- INVITE ---->| > |<------ 100 ------| > | X<--- PING ----| > | ECONNREFUSED ->| > |<------ 6XX ------| > |------- ACK ----->| > > And here's one if Alice's ISP removed that restriction: > > Alice's UAC Bob's UAS/UAC > | | > |----- INVITE ---->| > |<------ 100 ------| > |<----- PING ------| > |---- [2456]xx --->| > |<------ 200 ------| > |------- ACK ----->| > > In this case, Bob's UAS/UAC knows that it will be able (unless the rules > are changed mid-session) that proper message flow can occur. > > The introduction of a new 6xx code to indicate that the Contact > information presented in the INVITE is unusable would allow Bob's UAS to > tell Alice's UAC about this condition. > > This would fit with the intended use of the PING method in determining the > validity of the signaling path. This does impose extra cost on all TCP > calls. > > Is there an alternative way to detect this scenario? > > David -- 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 Mon Mar 06 18:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOh9-00076e-KZ; Mon, 06 Mar 2006 18:00:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOh8-00076Q-1w for sip@ietf.org; Mon, 06 Mar 2006 18:00:50 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGOh7-0005RR-KK for sip@ietf.org; Mon, 06 Mar 2006 18:00:49 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k26N0fX18174; Mon, 6 Mar 2006 18:00:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Date: Mon, 6 Mar 2006 17:00:25 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60ABC59D0@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Thread-Index: AcZBXg3hIjAKj6i/S9CApi/Wd0iQoAACSSQg From: "Samir Srivastava" To: "Jonathan Rosenberg" X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: sip@ietf.org, "Bharrat, Shaun" , Michael Procter , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Thx for detailed reply. My replies in line prefixed with SS>> Thx Samir Samir Srivastava wrote: > Both STUN CRLF and PING require change on the Proxy. We can have for=20 > PING whatever we want. > How STUN CLRF is better without changes on the existing Proxy ? The case that one needs to be concerned about is when the proxy doesn't support this mechanism, not when it does. SS>> Agreed >=20 > To send the response back for STUN CRLF, we need to change the proxies > too. But for PING, if proxy is not updated, and it is returning "501=20 > Method Not Implemented" we are okay. Well, my point is, that is not always going to be the case. Firstly, proxies are not supposed to have to know about new methods.=20 Quoting RFC3261: SS>> Agreed. It's my mistake regarding term proxy. Gernally Edge Proxies are B2BUA.=20 We need to take care of both. Refer Later comments for Proxy case. <<< Removed the quotes >>> Note the bit about unknown methods. So, a normal RFC3261 compliant proxy WILL NOT reject a PING request with a 501. You can force it to reject any request, including PING, by setting Max-Forwards to zero. But the point is, there is lots of other processing in a standard proxy that is going to interfere with your assumptions in this PING method. SS>> Fine. As you suggest use PING with Max-Forwards with zero. > And if proxy is good > enough, to have a configuration rule saying UnImplmented Methods are=20 > not authenticated, then we we are okay too. Normally all requests are authenticated. It is a security problem ot not authenticate a request just because its method is unknown. Imagine a new method NOT-INVITE, which carries SDP around, used to set up calls. Works much like invite, but I changed the method name. I can get free service from my proxy network if its not authenticated. SS>> Fine. Client resubmits the request with Credentials and with MAX-FORWARDS equal to 0. It should not trigger any other issue. > Though it does not offer Performance benefits of the shunting the SIP=20 > parser, but it does offer gradual upgrade. Which is not the case with=20 > STUN CRLF. No. This PING is a recipe for huge operational problems unless the proxies all support it. SS>> We are still in the process to arrive at conclusion. >=20 > May I ask, how many proxies are there which authenticate unimplemented > Methods ? Unimplemented? Careful here - we're talking about unknown methods.=20 Proxies arent supposed to know about methods except for INVITE, CANCEL ACK adn then everything else. You make it sounds like its a bug to authenticate unknown methods (mine does, btw). Its not. SS>> Okay. I was thinking in terms of Edge Proxy as B2BUA implementation. We can use MAX-FORWARWDS equal to 0 trick, for it not to be proxied. But let me pick another bad thing that can happen. Lets say our poor proxy is overloaded, probably from all of these PING requests. So, to quench traffic, it sends a 503 with a Retry-After, under the assumption that a compliant UAC will properly back off. But, the UAC doesn't (since UAC processing violates RFC 3261 for this method). The network continues to be overloaded with no recourse. Again, the source IP is likely to be blacklisted for non-compliance. SS>> Fine. We can add this to PING specification, it should honour 503. This will require more processing at client. We are fine with this. New Server with PING needs to check for overload variable, and Send 503 Retry After. This is not the case most of the time. We can still shunt the parser. BTW if server is overloaded with CRLF, what we will be doing ? The flip side of this problem is a client which sends a request called PING to a server, not realizing that a spec has been produced which redefines SIP processing for tihs specific method. As such, this client is expecting normal SIP processing for this request. It hits a server which supports this "extension". This is a real issue, btw - I am aware of implementations which use the method PING. Lets say the client is using this ping for a traceroute facility. So, it sends the request with a non-zero Max-Forwards. This hits a proxy which immediately rejects it since it supports the ping "extension". Now the client is going to get incorrect information from its traceroute processing. SS>> This is problem with the client due to name space collision. Client should fix it. It can happen with any new specification. If it is widely deployed and IETF wants to honour it, we can name method differently. Let us not forget that the stun mecahnism can still have a fallback to non-stun operation if the server doesnt support it. Stun messages are sent to the sip port only when the flag is present in the SIP URI indicating that the server can do the demux. We do EXACTLY this same thing with sigcomp, btw. So, if a client which supports sip outbound, has a URI for its outbound proxy which doesnt have this flag, it can resort to plain old OPTIONS with Max-Forwards: 0. No different than what happens with PING when the server doesn't support it, except we don't have the interop problems that PING will bring. SS>> We can do similar for PING. We can have the similar flags for PING support in URI if we don't want to use Require/Proxy-Require.=20 The old Proxy will honour the PING request with Tag for PING extension in Proxy Require with 420 Bad Extension, As I missing something here ? While the Proxy with PING specification will honour with 200 OK etc.=20 If there is any SIP traffic going on (Chatty IM Session, Register, Presenece and different Event Package notification etc ), we don't need to send the KEEP ALIVE. For STUN CRLF case, there needs to be additional coupling between SIP and STUN modules. This is an implementation issue, but needs to be taken into account. =20 =20 -Jonathan R. --=20 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 Mon Mar 06 18:22:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGP0T-0008Ly-Nn; Mon, 06 Mar 2006 18:20:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGP0Q-00087K-7L for sip@ietf.org; Mon, 06 Mar 2006 18:20:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGP0P-0006Eq-Sg for sip@ietf.org; Mon, 06 Mar 2006 18:20:46 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 06 Mar 2006 15:20:46 -0800 X-IronPort-AV: i="4.02,169,1139212800"; d="scan'208"; a="259932703:sNHT32601760" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k26NKjYg028273; Mon, 6 Mar 2006 15:20:45 -0800 (PST) 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.211); Mon, 6 Mar 2006 18:20:44 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 18:20:44 -0500 Message-ID: <440CC3CC.1020003@cisco.com> Date: Mon, 06 Mar 2006 18:20:44 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2006 23:20:44.0384 (UTC) FILETIME=[97B48600:01C64174] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF SIP List Subject: [Sip] Re: Dialog usage: Forking impacts X-BeenThere: sip@ietf.org X-Mailman-Version: 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 wrote: > Hi Paul, > > It is true that both 2 and 3 can establish early dialogs with 1. The issue, as I said in another mail, is that when 200 OK is received UA_1 may terminate all other early dialogs - not only specific dialoge usages. So your issue is that UA_1, by using a different interpretation of 3261, may decide it should terminate the complete dialog and all usages, and so have unintended consequences. Once again I agree that pointing this out would be a good thing. > The problem is of course that RFC3261 does not talk about dialog usages - only "full" dialoges. The way I think of it is 3261 did, at least implicitly, define both the concept of the dialog and the dialog usage, as distinct things. But it inadvertently gave them both the same name. Sometimes it uses that name to talk about dialogs, and other times to talk about dialog usages. The reader is left to sort out the ambiguity. Its as if you had two acquaintances, both named Bob, and you talk about them both to your friends: - Bob is a great software engineer - Bob is a slimy SOB lawyer - Bob is next to me coding up the latest dialog usage implementation - Bob is in Texas watching the defendant in his latest trial be executed - Bob has red hair Often you can figure out from context which Bob is being referenced. But not always. Paul > 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 Mon Mar 06 18:56:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPX1-0000Fi-AF; Mon, 06 Mar 2006 18:54:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPWz-0000AC-ND for sip@ietf.org; Mon, 06 Mar 2006 18:54:25 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPWy-0007O4-D5 for sip@ietf.org; Mon, 06 Mar 2006 18:54:25 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k26NsVTM027598 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Mar 2006 17:54:33 -0600 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60ABC57EA@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60ABC57EA@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Date: Mon, 6 Mar 2006 17:54:07 -0600 To: "Samir Srivastava" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, Juha Heinanen , Michael Procter , Alan Duric , "Bharrat, Shaun" , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 6, 2006, at 3:29 PM, Samir Srivastava wrote: > Gernally, Edge Proxies are implemented as B2BUA and they interpet > requests. Not in any model reasonably compliant with RFC 3261, including to my knowledge the normal behavior of P-CSCF in IMS (which may transition to a B2BUA in certain error-recovery cases). B2BUAs are not extension-method transparent. Proxies are. That's a key aspect of the SIP methodology, intended to decouple the message- routing infrastructure from the actual application. If you have to recode your proxies for every new application, you might as well use a Class-4 switch. -- 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 Mar 06 18:57:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPY2-000172-Am; Mon, 06 Mar 2006 18:55:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPY1-00016x-Es for sip@ietf.org; Mon, 06 Mar 2006 18:55:29 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPY0-0007Q4-8y for sip@ietf.org; Mon, 06 Mar 2006 18:55:29 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k26NtNbY049062; Mon, 6 Mar 2006 18:55:27 -0500 (EST) From: "Brett Tate" To: "'Jonathan Rosenberg'" , Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Date: Mon, 6 Mar 2006 18:56:26 -0500 Message-ID: <001c01c64179$94bcfea0$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <440C9DF1.8080401@cisco.com> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 > Let us not forget that the stun mechanism can still=20 > have a fallback to non-stun operation if the server=20 > doesn't support it.=20 > So, if a client which supports sip outbound, has=20 > a URI for its outbound proxy which doesn't have this=20 > flag, it can resort to plain old OPTIONS with=20 > Max-Forwards: 0. Since OPTIONS is frequently sent as a ping (instead of request for = options data), wouldn't it be beneficial to define a new option-tag to indicate = when OPTIONS is really just a ping? It does sound ridiculous; however it is = not much more so than having to use OPTIONS as a ping. The option-tag could indicate that the UAC plans to ignore all the = options data typically included within the 200 response. Thus it indicates a = desire for the UAS to not send such data. The UAC could include it in supported, proxy-require, and/or require depending on desired behavior. The main benefits would be related to capacity and security. And = devices constantly/mostly receiving OPTIONS as a ping, might start providing = more data in the response when OPTIONS actually used as it was intended. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 06 19:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPb9-0006G7-HQ; Mon, 06 Mar 2006 18:58:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPb8-0006BC-D2 for sip@ietf.org; Mon, 06 Mar 2006 18:58:42 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPb8-0007VD-3Z for sip@ietf.org; Mon, 06 Mar 2006 18:58:42 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k26NwwbR027623 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Mar 2006 17:59:00 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2ADF95EF-4D04-4BEE-80FA-2F05B7EBB9AD@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING request processing? Date: Mon, 6 Mar 2006 17:58:34 -0600 To: Hisham Khartabil X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "sip@ietf.org List" , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 6, 2006, at 9:02 AM, Hisham Khartabil wrote: > I promised to come back with hard real numbers on how long it will > take for a server to process and STUN request vs a SIP PING request Time alone is probably an insufficient determinant of performance in this case. I'm far more interested in how the alternatives affect the throughput, at saturation, of the node involved. As a secondary matter, I'm interested in how the methods affect the recovery of an overloaded node. -- 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 Mar 06 20:39:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGR92-0002PV-K3; Mon, 06 Mar 2006 20:37:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGR90-0002OS-Ra for sip@ietf.org; Mon, 06 Mar 2006 20:37:46 -0500 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGR90-0002eB-Ix for sip@ietf.org; Mon, 06 Mar 2006 20:37:46 -0500 Received: from [192.168.1.103] (pool-141-157-104-69.balt.east.verizon.net [141.157.104.69]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k271bZl29892; Mon, 6 Mar 2006 19:37:35 -0600 Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING requestprocessing? From: "Frank W. Miller" To: Jonathan Rosenberg In-Reply-To: <440C867B.6060506@cisco.com> References: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6CFC@not01-mxc01.citel.com> <440C867B.6060506@cisco.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Mon, 06 Mar 2006 20:37:34 -0500 Message-Id: <1141695455.2710.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, "Bharrat, Shaun" , Michael Procter , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2006-03-06 at 13:59 -0500, Jonathan Rosenberg wrote: > is lost. Well, you've changed the retransmit rules for PING from normal > SIP, and there are no retransmits. So, there is a timeout. We'll have a The dropping of retransmits was just added to the draft. The reason was that the duration that can occur between retransmissions in a NIT can be longer than what people were interested in for the NAT refresh interval, which was 15 seconds IIRC. You're point about stateful proxies is an interesting one. I'd also be interested in hearing about any experiences with implementations that do this and what kind of performance impacts have been observed on these stateful proxies. What I mean is, lets assume we have a stateful proxy that gets into a situation where its got alot of outstanding transactions that its tracking for some reason. What kind of performance hits are seen at that node, are there any? If the condition that caused the backup to occur clears, how long does the transient survive at the proxy? If we believe that dropping the retransmission behavior will seriously impact compatibility with 3261, we can of course change it back so the PING is retransmitted the same as any other request. Another possibility is to use NIT retransmissions but to simply modify the backoff so it never exceed 15 seconds. Such a compromise will likely cause fewer problems with intervening proxies and would meet the desire to have some outbound traffic every 15 seconds. The issue with this of course is that it bumps up the potential load on intervening servers during times when you want it to be bumped up the least. WRT to authentication, I believe it just doesn't make any sense to challenge a PING. It should be a short lived transient transaction that may or may not have anything to do with a session. If the PING is challenged, e.g. by an older implementation, the UAC should just give up and accept the 401 or 407 as the response. As far as blacklisting, I'm not sure what that means? Do you mean that the proxy is going to start dropping the PINGs on the floor rather than sending back some kind of response? Or do you mean that the Service Provider will cut off the network access or something? As far as STUN is concerned, IMHO, and its just MHO, multiplexing STUN and SIP is a much worse idea than trying to do something within the SIP protocol framework. I've already said that I believe STUN is a NAT discovery protocol only and that other functions should be done somewhere else. We just differ on that point. However, its clear that NAT discovery is at least one function of STUN and that NAT discovery is and will be required by other Internet protocols. For this reason alone, multiplexing it with SIP is too SIP-centric and does not make sense because any other protocol that needs STUN will bang into this architectural decision. 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 Mon Mar 06 20:42:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRBg-000587-Sp; Mon, 06 Mar 2006 20:40:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRBf-00057y-9C for sip@ietf.org; Mon, 06 Mar 2006 20:40:31 -0500 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRBf-0002jd-2U for sip@ietf.org; Mon, 06 Mar 2006 20:40:31 -0500 Received: from [192.168.1.103] (pool-141-157-104-69.balt.east.verizon.net [141.157.104.69]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k271ePl30021; Mon, 6 Mar 2006 19:40:25 -0600 Subject: RE: [Sip] RE: Comment on draft-fwmiller-sip-00 From: "Frank W. Miller" To: Samir Srivastava In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60ABC5675@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60ABC5675@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Mon, 06 Mar 2006 20:40:25 -0500 Message-Id: <1141695625.2710.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Cullen Jennings , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2006-03-06 at 14:25 -0600, Samir Srivastava wrote: > Additionally, With OPTIONS you can have Require and Proxy-Require. Which > is not allowed in > PING. So Proxies doesn't need to parse complete PING message. > > FM, Pl add the implementation guidelines with respect to Optimization > offered. One can find > "PING" string at the start of transport payload with standard compliant > clients. > There was a suggestion to add the ability to optionally carry Require and Proxy-Require. I personally don't think this is necessary but it needs to be consensed on I suppose. I will add a section on potential implementation optimizations. 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 Mon Mar 06 20:50:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRJn-0004F8-Fr; Mon, 06 Mar 2006 20:48:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRJk-00048s-F8 for sip@ietf.org; Mon, 06 Mar 2006 20:48:53 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRJj-0002tZ-8u for sip@ietf.org; Mon, 06 Mar 2006 20:48:52 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k271mlLw054444; Mon, 6 Mar 2006 20:48:50 -0500 (EST) From: "Brett Tate" To: "'Dean Willis'" Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING request processing? Date: Mon, 6 Mar 2006 20:49:50 -0500 Message-ID: <001d01c64189$6c1b95f0$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <2ADF95EF-4D04-4BEE-80FA-2F05B7EBB9AD@softarmor.com> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 promised to come back with hard real numbers on how long it will > > take for a server to process and STUN request vs a SIP PING request >=20 > Time alone is probably an insufficient determinant of=20 > performance in this case. I'm far more interested in=20 > how the alternatives affect the throughput, at saturation,=20 > of the node involved.=20 Thus far assuming it meets the requirements, I haven't heard of anything that would beat the "double CRLF" mechanism in this category for = connection oriented transports. > As a secondary matter, I'm interested in how the methods=20 > affect the recovery of an overloaded node. I'm not aware of much distinction among the proposals. The SIP 503 response works ok. And after draft-rosenberg-sipping-overload-reqs is resolved; hopefully the 503 response (or alternate solution) will work better. The "double CRLF" and STUN mechanisms would likely cause less overload. = And if an overload causes the connection/binding to be suspect, the = subsequent SIP request could trigger a 503 when needed. And depending upon how the mechanism is tied to the rest of the SIP messaging over the connection, potentially nothing extra really needs to = be sent over the connection/binding as long as something is being sent and received frequent enough. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 06 20:57:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRQH-0002pT-7G; Mon, 06 Mar 2006 20:55:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRQG-0002od-CP for sip@ietf.org; Mon, 06 Mar 2006 20:55:36 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRQF-00033M-1P for sip@ietf.org; Mon, 06 Mar 2006 20:55:36 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k271tetI027968 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Mar 2006 19:55:41 -0600 In-Reply-To: <1141695455.2710.27.camel@localhost.localdomain> References: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6CFC@not01-mxc01.citel.com> <440C867B.6060506@cisco.com> <1141695455.2710.27.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C020147-33D0-4A09-BFB1-16252F31F22F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING requestprocessing? Date: Mon, 6 Mar 2006 19:55:13 -0600 To: fwmiller@cornfed.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, Michael Procter , "Bharrat, Shaun" , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 6, 2006, at 7:37 PM, Frank W. Miller wrote: > > WRT to authentication, I believe it just doesn't make any sense to > challenge a PING. It should be a short lived transient transaction > that > may or may not have anything to do with a session. If the PING is > challenged, e.g. by an older implementation, the UAC should just > give up > and accept the 401 or 407 as the response. As far as blacklisting, > I'm > not sure what that means? Do you mean that the proxy is going to > start > dropping the PINGs on the floor rather than sending back some kind of > response? Or do you mean that the Service Provider will cut off the > network access or something? > Go to the bank. Insert your ATM card. Enter your PIN wrong a few times. You've been blacklisted. And you no longer have an ATM card, in most instances. Also, your picture has been taken and sent to Security, and they'll be calling you. Systems using this sort of defense will assume that the sending node is an attacker, and either actuate alarms or defensively start dropping requests from that node, or both. This leads to some interesting DOS opportunities, of course. Especially with UDP. -- 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 Mar 06 21:30:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRwZ-0004Th-VV; Mon, 06 Mar 2006 21:28:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRwY-0004QV-9H for sip@ietf.org; Mon, 06 Mar 2006 21:28:58 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRwV-00046i-US for sip@ietf.org; Mon, 06 Mar 2006 21:28:58 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k272Sk719021; Mon, 6 Mar 2006 21:28:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING request processing? Date: Mon, 6 Mar 2006 20:28:14 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60ABC5B25@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING request processing? Thread-Index: AcZBiVeZUvMmFSOrSHaZFuHZOtCFHgAAjDZg From: "Samir Srivastava" To: "Brett Tate" , "Dean Willis" X-Spam-Score: 0.1 (/) 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 Inline. Thx Samir I'm not aware of much distinction among the proposals. The SIP 503 response works ok. And after draft-rosenberg-sipping-overload-reqs is resolved; hopefully the 503 response (or alternate solution) will work better. The "double CRLF" and STUN mechanisms would likely cause less overload. And if an overload causes the connection/binding to be suspect, the subsequent SIP request could trigger a 503 when needed. SS>> We need to wait for Next Register Refresh, INVITE or other SIP request. And then do 503 for it. Will it not be too late to stop CRLF ? Or will there be new SIP Event to tell client not=20 to do STUN CRLF for specified time period. We are mixing so much STUN with SIP. IMHO, load is caused by CRLF and it should be stopped there with the response. STUN doesn't have mechanism for Retry-After as per 3489, so SIP PING with 503 is better in this case. Or add this logic in STUN-bis ? And depending upon how the mechanism is tied to the rest of the SIP messaging over the connection, potentially nothing extra really needs to be sent over the connection/binding as long as something is being sent and received frequent enough. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 06 23:41:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGTyo-0007tk-LQ; Mon, 06 Mar 2006 23:39:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGTyn-0007tf-Bf for sip@ietf.org; Mon, 06 Mar 2006 23:39:25 -0500 Received: from zproxy.gmail.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGTyn-0008Tk-1V for sip@ietf.org; Mon, 06 Mar 2006 23:39:25 -0500 Received: by zproxy.gmail.com with SMTP id 4so1391638nzn for ; Mon, 06 Mar 2006 20:39:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=sX26jBEi2uDhSehHaa2Cm1dtDopgRFktNjGem8pMg4jbFU0JsgVJpfhw4uBXSe4DyfDlNDkUGu5Gavs+nVxT6DOMhScC8epa/QYRutw0wrWB5WGHFeayu/bfvtOtFycGpuQ/d03CFv3E8+RTKk+UEdlK8p1tQzTsZd5Kl/S0Lvs= Received: by 10.65.206.20 with SMTP id i20mr3003707qbq; Mon, 06 Mar 2006 20:39:24 -0800 (PST) Received: by 10.64.179.5 with HTTP; Mon, 6 Mar 2006 20:39:24 -0800 (PST) Message-ID: <1a0d206e0603062039h24f73cadr1106d71371be94b2@mail.gmail.com> Date: Tue, 7 Mar 2006 10:09:24 +0530 From: "Allen Paul" To: sip-implementors@cs.columbia.edu, sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: Subject: [Sip] QoS parameters in SDP as per RFC 3312 X-BeenThere: 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="===============2123603818==" Errors-To: sip-bounces@ietf.org --===============2123603818== Content-Type: multipart/alternative; boundary="----=_Part_249_10144007.1141706364378" ------=_Part_249_10144007.1141706364378 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, We are implementing a one way video streaming application with QoS.Whatshould be the qos parameters in SDP for a streaming application(Video is send from offerer to answerer),different implementation seems to be behavin= g different ways for qos negotiation.Would like to know which of the followin= g call flow is valid Flow 1 INVITE a=3Dcurr:qos local none a=3Dcurr:qos remote none a=3Ddes:qos mandatory local send a=3Ddes:qos none remote send 183 a=3Dcurr:qos local none a=3Dcurr:qos remote none a=3Ddes:qos mandatory local recv a=3Ddes:qos mandatory remote recv a=3Dconf:qos remote recv PRACK a=3Dcurr:qos local none a=3Dcurr:qos remote none a=3Ddes:qos mandatory local send a=3Ddes:qos mandatory remote send 200 OK for PRACK a=3Dcurr:qos local none a=3Dcurr:qos remote none a=3Ddes:qos mandatory local recv a=3Ddes:qos mandatory remote recv a=3Dconf:qos remote recv UPDATE a=3Dcurr:qos local send a=3Dcurr:qos remote none a=3Ddes:qos mandatory local send a=3Ddes:qos mandatory remote send 200 OK UPDATE a=3Dcurr:qos local recv a=3Dcurr:qos remote recv a=3Ddes:qos mandatory local recv a=3Ddes:qos mandatory remote recv Flow 2 INVITE a=3Dcurr:qos local none a=3Dcurr:qos remote none a=3Ddes:qos mandatory local send a=3Ddes:qos mandatory remote recv 183 a=3Dcurr:qos local none a=3Dcurr:qos remote none a=3Ddes:qos mandatory local recv a=3Ddes:qos mandatory remote send a=3Dconf:qos remote send PRACK a=3Dcurr:qos local none a=3Dcurr:qos remote none a=3Ddes:qos mandatory local send a=3Ddes:qos mandatory remote recv 200 OK for PRACK a=3Dcurr:qos local none a=3Dcurr:qos remote none a=3Ddes:qos mandatory local recv a=3Ddes:qos mandatory remote send a=3Dconf:qos remote send UPDATE a=3Dcurr:qos local sendrecv a=3Dcurr:qos remote none a=3Ddes:qos mandatory local send a=3Ddes:qos mandatory remote recv 200 OK UPDATE a=3Dcurr:qos local sendrecv a=3Dcurr:qos remote sendrecv a=3Ddes:qos mandatory local recv a=3Ddes:qos mandatory remote send Regards Allen ------=_Part_249_10144007.1141706364378 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

   We are implementing a one way video streaming application with QoS.What should be the qos parameters in SDP for a streaming application(Video is send from offerer to answerer),different implementation seems to be behaving different ways for qos negotiation.Would like to know which of the following call flow is valid
Flow 1
  INVITE
     a=3Dcurr:qos local none
     a=3Dcurr:qos remote none
     a=3Ddes:qos mandatory local send
     a=3Ddes:qos none remote send
  183
     a=3Dcurr:qos local none
     a=3Dcurr:qos remote none
     a=3Ddes:qos mandatory local recv
     a=3Ddes:qos mandatory remote recv
     a=3Dconf:qos remote recv
 PRACK
     a=3Dcurr:qos local none
     a=3Dcurr:qos remote none
     a=3Ddes:qos mandatory local send
     a=3Ddes:qos mandatory remote send
200 OK for PRACK
     a=3Dcurr:qos local none
     a=3Dcurr:qos remote none
     a=3Ddes:qos mandatory local recv
     a=3Ddes:qos mandatory remote recv        a=3Dconf:qos remote recv
UPDATE
      a=3Dcurr:qos local send
     a=3Dcurr:qos remote none
     a=3Ddes:qos mandatory local send
     a=3Ddes:qos mandatory remote send
200 OK UPDATE
     a=3Dcurr:qos local recv
     a=3Dcurr:qos remote recv
     a=3Ddes:qos mandatory local recv
     a=3Ddes:qos mandatory remote recv


Flow 2

  INVITE
     a=3Dcurr:qos local none
     a=3Dcurr:qos remote none
     a=3Ddes:qos mandatory local send
     a=3Ddes:qos mandatory remote recv
  183
     a=3Dcurr:qos local none
     a=3Dcurr:qos remote none
     a=3Ddes:qos mandatory local recv
     a=3Ddes:qos mandatory remote send
     a=3Dconf:qos remote send
 PRACK
     a=3Dcurr:qos local none
     a=3Dcurr:qos remote none
     a=3Ddes:qos mandatory local send
     a=3Ddes:qos mandatory remote recv
200 OK for PRACK
     a=3Dcurr:qos local none
     a=3Dcurr:qos remote none
     a=3Ddes:qos mandatory local recv
     a=3Ddes:qos mandatory remote send
     a=3Dconf:qos remote send
UPDATE
      a=3Dcurr:qos local sendrecv
     a=3Dcurr:qos remote none
     a=3Ddes:qos mandatory local send
     a=3Ddes:qos mandatory remote recv
200 OK UPDATE
     a=3Dcurr:qos local sendrecv
     a=3Dcurr:qos remote sendrecv
     a=3Ddes:qos mandatory local recv
     a=3Ddes:qos mandatory remote send


Regards
Allen

   
    
------=_Part_249_10144007.1141706364378-- --===============2123603818== 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 --===============2123603818==-- From sip-bounces@ietf.org Tue Mar 07 01:23:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGVZR-0002wp-9g; Tue, 07 Mar 2006 01:21:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGVZQ-0002vO-4I for sip@ietf.org; Tue, 07 Mar 2006 01:21:20 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGVZO-0002lS-BC for sip@ietf.org; Tue, 07 Mar 2006 01:21:20 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 7F780140408; Tue, 7 Mar 2006 08:21:16 +0200 (EET) Received: from rautu (unknown [202.73.194.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 30E0D140402; Tue, 7 Mar 2006 08:21:10 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id D097DF027C; Tue, 7 Mar 2006 08:21:20 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17421.9824.795536.273253@rautu.tutpro.com> Date: Tue, 7 Mar 2006 08:21:20 +0200 From: Juha Heinanen To: "Samir Srivastava" Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60ABC59D0@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60ABC59D0@zrc2hxm2.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org, Michael Procter , "Bharrat, Shaun" , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava writes: > Normally all requests are authenticated. It is a security problem ot not > authenticate a request just because its method is unknown. Imagine a new > method NOT-INVITE, which carries SDP around, used to set up calls. Works > much like invite, but I changed the method name. I can get free service > from my proxy network if its not authenticated. this goes too far. you must have lived to long in bell-head world. as i told before, proxies route sip requests. if you want to charge for that, it doesn't matter if request is INVITE or NON-INVITE. -- 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 Mar 07 03:10:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGXFT-0001co-6M; Tue, 07 Mar 2006 03:08:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGX3e-0004sK-Oo for sip@ietf.org; Tue, 07 Mar 2006 02:56:39 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGX3A-00068z-9Z for sip@ietf.org; Tue, 07 Mar 2006 02:56:12 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k277u6o2006913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Mar 2006 08:56:06 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k277u1K5011219; Tue, 7 Mar 2006 08:56:01 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k277tuuf011218; Tue, 7 Mar 2006 08:55:56 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f From: Hans Persson To: sip@ietf.org Content-Type: text/plain; charset=iso-8859-4 Content-Transfer-Encoding: quoted-printable Organization: Ingate Systems Date: Tue, 07 Mar 2006 08:55:55 +0100 Message-Id: <1141718155.10301.14.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Tue, 07 Mar 2006 08:56:06 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] SBCs and draft-ietf-sip-identity-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 just went back and had a look at draft-ietf-sip-identity-06. As far as I can see, an Identity header really says two things at the same time. 1) The sender is who he claims to be. 2) The message looks like it did when it was sent. Both these functions are nice in an ideal world, but many people will have SBCs, B2BUAs, or SIP-aware firewalls in their call paths. These will modify SDP and probably the Contact header. As far as I can see there is no discussion in the draft about this at all, apart from the probably na=B5ve assumption that it shouldn't happen. It would be nice with guidelines about what these types of entities should do. Should they modify what they need to modify and leave the rest (including the now non-verifiable Identity header, to make it clear that something happened along the way) or should they remove the Identity header as well? In this type of scenario, the integrity verification of the SIP message will fail. Personally, I'd rather still have a (possibly somewhat weaker) verification that the sender is who he claims to be than nothing. Hans --=20 Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 07 03:58:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGXzr-0001bi-FN; Tue, 07 Mar 2006 03:56:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGXzp-0001bd-Uk for sip@ietf.org; Tue, 07 Mar 2006 03:56:45 -0500 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGXzn-0001Qd-Ge for sip@ietf.org; Tue, 07 Mar 2006 03:56:45 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 65B4874565; Tue, 7 Mar 2006 09:56:42 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12134-01-87; Tue, 7 Mar 2006 09:56:41 +0100 (CET) Received: from dhcp-wavelan-v-202.publik.su.se (dhcp-wavelan-v-202.publik.su.se [130.237.168.202]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id E06D874559; Tue, 7 Mar 2006 09:56:41 +0100 (CET) From: Fredrik Thulin Date: Tue, 7 Mar 2006 09:56:38 +0100 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Disposition: inline To: Jonathan Rosenberg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200603070956.38694.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.526 tagged_above=-99 required=7 tests=[AWL=0.139, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org Subject: [Sip] Questions on GRUU draft 06 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 read draft-ietf-sip-gruu-06.txt, and implemented all the applicable parts for my open source proxy (YXA). Generally I must say that GRUUs are pretty straight forward, if you don't have to deal with the edge proxy problem (I don't, because my application serving as an edge proxy handles REGISTER itself without forwarding it to a 'home proxy' (distributed location database)). I have two questions which I really couldn't find an answer to myself : 8.4.1 Request Targeting : > If the Request URI is an > AOR against which there are multiple registered contacts with the > same instance ID parameter, the proxy MUST populate the target set so > that there is never more than one contact at a time with a given > instance ID. Does this means the GRUU specification updates how a proxy should handle requests to non-GRUUs as well? If two GRUU capable user agents have registered with an AOR, gotten two different GRUUs, and then a request arrives for the AoR (_not_ one of the GRUUs), does this apply? This sounds a bit weird to me. Maybe the scenario is about a request to a Request-URI which is a GRUU? That is not perfectly clear to me at least. 7.1.2.1 Processing a REGISTER Request : > When generating the 200 (OK) response to the REGISTER request, the > procedures of step 8 of Section 10.3 of RFC 3261 are followed. > Furthermore, for each Contact header field value placed in the > response, if the registrar has stored an instance ID associated with > that contact, that instance ID is returned as a Contact header field > parameter. Why is this needed? The user agent already knows which instance id it supplied, so it can't be for the user agents benefit the proxy puts all the instance ids in there. Is it so that other partys can see the instance id of a user agent? I'm not saying that it is bad, but why is it needed? The user agent should be able to find it's allocated GRUU by just looking for the contact URI it provided? /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 07 04:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGYoq-0005mD-Sf; Tue, 07 Mar 2006 04:49:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGYoq-0005lG-34 for sip@ietf.org; Tue, 07 Mar 2006 04:49:28 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGYop-0003Z5-BP for sip@ietf.org; Tue, 07 Mar 2006 04:49:28 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IVR00K014HTDY@siemenscomms.co.uk> for sip@ietf.org; Tue, 07 Mar 2006 09:46:42 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IVR00IAW4HTU3@siemenscomms.co.uk>; Tue, 07 Mar 2006 09:46:41 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 07 Mar 2006 09:49:26 +0000 Content-return: allowed Date: Tue, 07 Mar 2006 09:49:25 +0000 From: "Elwell, John" Subject: RE: [Sip] Updated connected-identity draft To: Ilan Avner , "Alexeitsev, D" Message-id: <50B1CBA96870A34799A506B2313F26670841D1D0@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b 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="===============0228962863==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0228962863== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_2ODz274HB2X2zIZ9raauyA)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_2ODz274HB2X2zIZ9raauyA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Ilan, =20 See below. =20 John _____ =20 From: Ilan Avner [mailto:ilan.avner@audiocodes.com]=20 Sent: 06 March 2006 20:06 To: Elwell, John; Alexeitsev, D Cc: sip@ietf.org Subject: RE: [Sip] Updated connected-identity draft Hi all, I have two questions regarding the identity draft: =20 1.Does the new draft address a feature implemented on the PSTN world = called COLR (Connected number presentation restriction), this feature is about sending the connected number as a restricted number. the solution for sending restricted numbers as the calling number (in = the first INVITE) is to use the p-asserted header, what about the connected number? [JRE] The Identity header defined in the sip-identity draft already = makes provision for anonymous users, and with my draft that provision can be applied equally to connected users. =20 2.In case the called number had changed after sending 180, as I = understand the UAS should send an UPDATE request with the new number in the from header. what about the 200 O.K for the INVITE, should the To header also change = to reflect the new called number or should be the same as the To header = sent in the 180? [JRE] That is an open issue in the draft - opinions are welcome.=20 =20 Thanks. =20 Ilan. _____ =20 =D7=9E=D7=90=D7=AA: Elwell, John [mailto:john.elwell@siemens.com] =D7=A0=D7=A9=D7=9C=D7=97: =D7=91 06/03/2006 18:35 =D7=90=D7=9C: Alexeitsev, D =D7=A2=D7=95=D7=AA=D7=A7 =D7=9C=D7=99=D7=93=D7=99=D7=A2=D7=94: = sip@ietf.org =D7=A0=D7=95=D7=A9=D7=90: RE: [Sip] Updated connected-identity draft Denis, =20 The disadvantage with changing the To header field URI in the INVITE response is that authentication using the Identity header cannot be achieved. It may be possible to rely on other means to ensure the authenticity of this information (e.g., SIPS + transitive trust +use of = TLS on the last hop too). It depends whether there is sufficient interest = from the community in this. =20 John _____ =20 From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 Sent: 06 March 2006 13:57 To: Elwell, John Cc: sip@ietf.org Subject: AW: [Sip] Updated connected-identity draft Hello Jonh =20 Referring to the open issue about the updated To: header in the final = INVITE response: =20 Would it not be possible to have a general solution that would allow = both the change of the To: header URI in the final INVITE response, if the = COLP information is available at that time, and the midcall change using the UPDATE method? =20 The tests we made with several SIP hard and soft phones show, that the current implementations would accept the changed To: header URI in the = final INVITE response without any session influence. The changed To: header = URI information would currently not be presented to the user by the UACs, = but this is a user interface issue without protocol impact. =20 In the subsequent requests the UACs would still use the original To: = header URI, so this could be mentioned in the draft to increase the interoperability with current implementations. =20 Greetings, Denis Alexeistev -----Urspr=C3=BCngliche Nachricht----- Von: Elwell, John [mailto:john.elwell@siemens.com]=20 Gesendet: Montag, 6. M=C3=A4rz 2006 11:50 An: sip@ietf.org Betreff: [Sip] Updated connected-identity draft draft-elwell-sip-connected-identity is now available:=20 =20 http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-= 01.t xt=20 Compared with the 00 version, this has changed considerably and is = intended to reflect decisions made in Vancouver. It exploits the ability to = change the From URI during a dialog, so that requests in the reverse direction = can place the source URI in the From header field and the Identity header = can be used to provide authentication, rather having to introduce new headers. Comments would be appreciated. I would like to get this adopted as a = SIP WG item in Dallas. John=20 --Boundary_(ID_2ODz274HB2X2zIZ9raauyA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Nachricht
Ilan,
 
See below.
 
John

From: Ilan Avner=20 [mailto:ilan.avner@audiocodes.com]
Sent: 06 March 2006=20 20:06
To: Elwell, John; Alexeitsev, D
Cc:=20 sip@ietf.org
Subject: RE: [Sip] Updated connected-identity=20 draft

Hi = all,
I have two questions = regarding the=20 identity draft:
 
1.Does the new draft address a feature = implemented on the=20 PSTN world called COLR (Connected number presentation restriction), = this=20 feature is about sending the connected number as a restricted=20 number.
the = solution for=20 sending restricted numbers as the calling number (in the first = INVITE) is to=20 use the p-asserted header, what about the connected number?
[JRE] The Identity=20 header defined in the sip-identity draft already makes provision = for=20 anonymous users, and with my draft that provision can be applied = equally to=20 connected users.
 
2.In = case the called=20 number had changed after sending 180, as I understand the UAS should = send an=20 UPDATE request with the new number in the from = header.
what = about the 200 O.K=20 for the INVITE, should the To header also change to reflect the new = called=20 number or should be the same as the To header sent in the = 180?
[JRE] That is an open=20 issue in the draft - opinions are=20 welcome. 
 
Thanks.
 
Ilan.

=D7=9E=D7=90=D7=AA: Elwell, John=20 [mailto:john.elwell@siemens.com]
=D7=A0=D7=A9=D7=9C=D7=97: = =D7=91 06/03/2006=20 18:35
=D7=90=D7=9C: Alexeitsev, D
=D7=A2=D7=95=D7=AA=D7= =A7 =D7=9C=D7=99=D7=93=D7=99=D7=A2=D7=94:=20 sip@ietf.org
=D7=A0=D7=95=D7=A9=D7=90: RE: [Sip] Updated = connected-identity=20 draft

Denis,
 
The disadvantage with changing the To header = field URI in=20 the INVITE response is that authentication using the Identity header = cannot be=20 achieved. It may be possible to rely on other means to ensure the = authenticity=20 of this information (e.g., SIPS + transitive trust +use of TLS on the = last hop=20 too). It depends whether there is sufficient interest from the = community in=20 this.
 
John

From: Alexeitsev, D=20 [mailto:D.Alexeitsev@t-com.net]
Sent: 06 March 2006=20 13:57
To: Elwell, John
Cc:=20 sip@ietf.org
Subject: AW: [Sip] Updated = connected-identity=20 draft

Hello Jonh
 
Referring to the open issue about the updated To: header = in the final=20 INVITE response:
 
Would it not be possible to have a general solution that = would allow=20 both the change of the To: header URI in the final INVITE response, = if the=20 COLP information is available at that time, and the midcall change = using the=20 UPDATE method?
 
The tests we made with several SIP hard and soft phones = show, that=20 the current implementations would accept the changed To: header URI = in the=20 final INVITE response without any session influence. The changed = To: header=20 URI information would currently not be presented to the user by the = UACs,=20 but this is a user interface issue without protocol=20 impact.
 
In=20 the subsequent requests the UACs would still use the original To: = header=20 URI, so this could be mentioned in the draft to increase the=20 interoperability with current implementations.
 
Greetings,
Denis Alexeistev
-----Urspr=C3=BCngliche=20 Nachricht-----
Von: Elwell, John = [mailto:john.elwell@siemens.com]=20
Gesendet: Montag, 6. M=C3=A4rz 2006 11:50
An:=20 sip@ietf.org
Betreff: [Sip] Updated connected-identity=20 draft

draft-elwell-sip-connected-identity is now=20 available:
http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-= identity-01.txt=20

Compared with the 00 version, this = has changed=20 considerably and is intended to reflect decisions made in = Vancouver. It=20 exploits the ability to change the From URI during a dialog, so = that=20 requests in the reverse direction can place the source URI in the = From=20 header field and the Identity header can be used to provide=20 authentication, rather having to introduce new headers. Comments = would be=20 appreciated. I would like to get this adopted as a SIP WG item in = Dallas.

John=20

--Boundary_(ID_2ODz274HB2X2zIZ9raauyA)-- --===============0228962863== 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 --===============0228962863==-- From sip-bounces@ietf.org Tue Mar 07 06:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGa7E-0006El-EY; Tue, 07 Mar 2006 06:12:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGa7D-0006Eg-4S for sip@ietf.org; Tue, 07 Mar 2006 06:12:31 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGa7B-0006jT-OJ for sip@ietf.org; Tue, 07 Mar 2006 06:12:31 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k27BC8Du019352; Tue, 7 Mar 2006 05:12:08 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Mar 2006 11:12:07 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0124F8A00@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Samir Srivastava , Jonathan Rosenberg , Michael Procter Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing fas terthan a SIP PING requestprocessing? Date: Tue, 7 Mar 2006 11:12:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: sip@ietf.org, "Bharrat, Shaun" , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Dean has already mentioned, the IMS P-CSCF treats unimplemented methods the same as defined methods as far as authentication is concerned. Authentication is performed at registration - this creates a security association for that contact, and then all subsequent requests and responses use that security association. Anything outside the security association apart from an initial REGISTER request is therefore discarded before it reaches the SIP transaction processing. Note that in addition, IMS uses SIGCOMP. After processing the new method two ways through SIGCOMP, do the figures still look the same? While it would be possible to define a dictionary entry for the entirety of such a new method, this would then mean that any such method would have to be implemented character for character exactly the same as in the dictionary. Therefore in the evaluation of the different mechanisms, please ensure that the impact of SIGCOMP on the efficiency is also taken into account. regards Keith > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: 06 March 2006 20:00 > To: Jonathan Rosenberg; Michael Procter > Cc: sip@ietf.org; Bharrat, Shaun; Alan Duric; Dusan Stevanovic > Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing > fasterthan a SIP PING requestprocessing? > > > > Both STUN CRLF and PING require change on the Proxy. We can have for > PING whatever we want. > How STUN CLRF is better without changes on the existing Proxy ? > > To send the response back for STUN CRLF, we need to change the proxies > too. But for PING, if proxy is not updated, and it is returning "501 > Method Not Implemented" we are okay. And if proxy is good > enough, to have a configuration rule saying UnImplmented > Methods are not > authenticated, then we > we are okay too. Though it does not offer Performance benefits of the > shunting the SIP parser, but it does offer gradual upgrade. > Which is not > the case with STUN CRLF. > > May I ask, how many proxies are there which authenticate unimplemented > Methods ? > > Thx > Samir > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Monday, March 06, 2006 10:59 AM > To: Michael Procter > Cc: sip@ietf.org; Bharrat, Shaun; Alan Duric; Dusan Stevanovic > Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing > fasterthan a SIP PING requestprocessing? > > inline. > > Michael Procter wrote: > > > Bharrat, Shaun wrote: > > > >>Now that I understand what is actually being done, I guess > my question > > >>is why you would have expected the numbers to be any different? > > > > [...] > > > >>If we are "allowed" to skip the SIP processing (i.e. it's > not really a > > >>SIP packet), then I agree that we can make the processing time of a > >>PING arbitrarily close to a STUN packet processing. > However, if we are > > >>not, I don't agree that this is a valid comparison of a SIP-based > >>keepalive versus a STUN based keepalive. > > > > > > I think the point is that the message has sufficient SIP > headers that > > it can be parsed and rejected (501) by a stack that doesn't support > > the extension. A rejection is an acceptable response to the PING > > request, > > > > So, the PING request is in some sense backwards-compatible with > > existing code. > > Thats my beef with this whole thing. That its "in some sense" > backwards > compatible, but not really. > > You are taking something that LOOKS like SIP, but is fundamentally NOT > SIP, and sending to a server in the hopes that the right > thing happens. > However, in the real world, odd things will always happen. Let me give > some examples. > > UAC sends the PING request to its proxy. Proxy doesnt support > the method > but forwards it on to another proxy, ignorning max-forwards (some > elements do this, as they serve as 'fronts' to the real proxy). Packet > is lost. Well, you've changed the retransmit rules for PING > from normal > SIP, and there are no retransmits. So, there is a timeout. > We'll have a > nice race condition, first of all, since the outbound proxy, having > thought this was normal SIP, will generate a 408 at some point, but > probably after the UAC gives up. Depends on how you define > your new PING > protocol transaction timers relative to real sip. Assuming though that > the UAC times out first, the UAC will think that its proxy is > down, but > its not. Seems really bad to me. > > Here's another funny case. PING goes to a proxy, which doesn't know > about PING, but wants to authenticate the request. So, it > responds with > a 401 and challenges the request. Well, you might say it worked fine - > nat binding kept alive. However, many proxies will set off alarms with > their intrusion detection systems on repeated 401 messages > from the same > source IP, so your client may find itself banned from the > network pretty > quickly. > > Both of these problems can be fixed by putting Proxy-Require > and Require > in. However, that defeats the whole point of this mechanism, to be > "backwards compatible" with existing SIP. So, if you do that, may as > well use STUN. > > So, to be clear, I think that this whole idea of something that looks > like SIP, but isn't, in the supposed hopes of being "backwards > compatible" with existing equipment, is a big, big mistake, and will > result in all kinds of unpredicable and really hard to debug > problems in > the real world. > > > > Of course, newer implementations may choose to > > optimise the processing for it, so that they can get > performance that > > is equivalent to STUN, but there is no need to do so for > the feature > > to work. Implementing the fast-path processing is > therefore purely an > > > implementation issue, not a protocol compliance issue. > > Wrong, as I have pointed out. As soon as you make a change that alters > MUST-strength processing in clients (as the PING method has), you have > introduced interoperability problems. > > -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 Tue Mar 07 07:28:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGbGS-0008K7-5F; Tue, 07 Mar 2006 07:26:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGbGQ-0008Ih-4z for sip@ietf.org; Tue, 07 Mar 2006 07:26:06 -0500 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGbGO-0000dG-NU for sip@ietf.org; Tue, 07 Mar 2006 07:26:06 -0500 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 7 Mar 2006 13:26:27 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Mar 2006 13:26:03 +0100 Message-Id: From: "Alexeitsev, D" To: john.elwell@siemens.com Subject: AW: [Sip] Updated connected-identity draft Date: Tue, 7 Mar 2006 13:25:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org, ilan.avner@audiocodes.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: , Content-Type: multipart/mixed; boundary="===============1652221042==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1652221042== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C641E2.45C09E1B" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C641E2.45C09E1B Content-Type: text/plain Hello John see inline 2.In case the called number had changed after sending 180, as I understand the UAS should send an UPDATE request with the new number in the from header. what about the 200 O.K for the INVITE, should the To header also change to reflect the new called number or should be the same as the To header sent in the 180? [JRE] That is an open issue in the draft - opinions are welcome. As I said before, I think, that changing the To: header URI in the 200 Ok aligns nicely with the UPDATE procedure and additionally would also support the trust domain scenario. In this case the proposed procedure would gain much wider acceptance. Greetings, Denis Alexeitsev ------_=_NextPart_001_01C641E2.45C09E1B Content-Type: text/html Nachricht
Hello John
 
see inline
2.In case the called number had changed after sending 180, as I understand the UAS should send an UPDATE request with the new number in the from header.
what about the 200 O.K for the INVITE, should the To header also change to reflect the new called number or should be the same as the To header sent in the 180?
[JRE] That is an open issue in the draft - opinions are welcome.  
 
As I said before, I think, that changing the To: header URI in the 200 Ok aligns nicely with the UPDATE procedure and additionally would also support the trust domain scenario.
 
In this case the proposed procedure would gain much wider acceptance.
 
Greetings,
Denis Alexeitsev
 
 
------_=_NextPart_001_01C641E2.45C09E1B-- --===============1652221042== 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 --===============1652221042==-- From sip-bounces@ietf.org Tue Mar 07 09:45:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdPD-0001SX-SK; Tue, 07 Mar 2006 09:43:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdPC-0001SS-N5 for sip@ietf.org; Tue, 07 Mar 2006 09:43:18 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdPB-000556-3W for sip@ietf.org; Tue, 07 Mar 2006 09:43:18 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3810D5D7; Tue, 7 Mar 2006 15:43:16 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 15:43:15 +0100 Received: from [136.225.183.92] ([136.225.183.92]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 15:43:12 +0100 From: "Christer Holmberg" To: "Paul Kyzivat" Date: Tue, 7 Mar 2006 16:38:22 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 07 Mar 2006 14:43:15.0306 (UTC) FILETIME=[776CF4A0:01C641F5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF SIP List Subject: [Sip] Re: Dialog usage: Forking impacts X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, Yes, the issue is that UA_1 would terminate the whole dialog - including = all usages. However, 3261 does not mandate the termination of dialogs - it simply says = that there are currently no applications defined where multiple fully = established dialogs would be kept alive within a session. And, that of = course makes the whole thing even more interesting :) 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 Mar 07 10:15:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdrx-0000it-Ix; Tue, 07 Mar 2006 10:13:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdrw-0000ij-Kd for sip@ietf.org; Tue, 07 Mar 2006 10:13:00 -0500 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdrv-000665-7E for sip@ietf.org; Tue, 07 Mar 2006 10:13:00 -0500 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k27FCvvw032441; Tue, 7 Mar 2006 16:12:57 +0100 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id k27FCusY026752; Tue, 7 Mar 2006 16:12:57 +0100 Message-ID: <440DA2FD.9020706@alcatel.fr> Date: Tue, 07 Mar 2006 16:13:01 +0100 From: Thomas Froment Organization: Alcatel User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sip@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] Clarification on RFC 3261, section 10.3 =?iso-8859-1?q?=A76?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RFC 3261 section 10.3 (Processing REGISTER Requests) states: part 6: The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. If the Contact header field is present, the registrar checks if there is one Contact field value that contains the special value "*" and an Expires field. If the request has additional Contact fields or an expiration time other than zero, the request is invalid, and the server MUST return a 400 (Invalid Request) and skip the remaining steps. If not, the registrar checks whether the Call-ID agrees with the value stored for each binding. If not, it MUST remove the binding. *If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise, the update MUST be aborted and the request fails.* I am *exactly* in the last case where I MUST abort the update and "fail the request": WHAT does exactly mean "FAIL the request": option 1 -> should I answer error 4xx, or 5xx ? if yes, which one? option 2-> should I just ignore the update and still answer 200 OK ? This test case is performed in ETSI RFC 3261 test suite, and this test suite assume option 2 is correct, but it does not seem so clear reading RFC... Any help ? Thanks, 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 Mar 07 10:22:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdz1-0006lO-J4; Tue, 07 Mar 2006 10:20:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdyz-0006ke-Q4 for sip@ietf.org; Tue, 07 Mar 2006 10:20:17 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdyx-0006Hp-Uh for sip@ietf.org; Tue, 07 Mar 2006 10:20:17 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 313D819445F for ; Tue, 7 Mar 2006 16:20:14 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 16:18:40 +0100 In-Reply-To: <440C9DF1.8080401@cisco.com> References: <62B9B0847CC47543B6B3B5E26BD268E60ABC55EE@zrc2hxm2.corp.nortel.com> <440C9DF1.8080401@cisco.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3407827ed945da187db8dae74af28459@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Date: Tue, 7 Mar 2006 16:20:39 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 07 Mar 2006 15:18:40.0701 (UTC) FILETIME=[6A427ED0:01C641FA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: sip@ietf.org, Michael Procter , "Bharrat, Shaun" , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 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 wanted to note that I'm not yet in favour of either mechanism. I'm=20= just trying to find the best solution by attacking until one breaks.=20 The solution needs to be reasonably simple and fast to deploy. We want=20= to make sure that the chosen mechanism is the appropriate one for all=20 reasons. More inline... On Mar 6, 2006, at 9:39 PM, Jonathan Rosenberg wrote: > > > Firstly, proxies are not supposed to have to know about new methods.=20= > Quoting RFC3261: > >> This is a model of proxy behavior, not of software. An >> implementation is free to take any approach that replicates the >> external behavior this model defines. >> For all new requests, including any with unknown methods, an=20 >> element >> intending to proxy the request MUST: >> 1. Validate the request (Section 16.3) >> 2. Preprocess routing information (Section 16.4) >> 3. Determine target(s) for the request (Section 16.5) >> +--------------------+ >> | | +---+ >> | | | C | >> | | | T | >> | | +---+ >> +---+ | Proxy | +---+ CT =3D Client Transaction >> | S | | "Higher" Layer | | C | >> | T | | | | T | ST =3D Server Transaction >> +---+ | | +---+ >> | | +---+ >> | | | C | >> | | | T | >> | | +---+ >> +--------------------+ >> Figure 3: Stateful Proxy Model >> Rosenberg, et. al. Standards Track [Page=20= >> 93] >> =0C >> RFC 3261 SIP: Session Initiation Protocol June=20= >> 2002 >> 4. Forward the request to each target (Section 16.6) >> 5. Process all responses (Section 16.7) > > > Note the bit about unknown methods. Note the bit that says "intending to proxy a request". I would assume=20 the PING request has a request-uri pointing to that proxy and therefore=20= the proxy does not intend to proxy that PING request. > >> Though it does not offer Performance benefits of the >> shunting the SIP parser, but it does offer gradual upgrade. Which is=20= >> not >> the case with STUN CRLF. > > No. This PING is a recipe for huge operational problems unless the=20 > proxies all support it. Well, I don't think I'm crazy enough to deploy UAs that use PING=20 without adding support to it in my network. > >> May I ask, how many proxies are there which authenticate = unimplemented >> Methods ? > > Unimplemented? Careful here - we're talking about unknown methods.=20 > Proxies arent supposed to know about methods except for INVITE, CANCEL=20= > ACK adn then everything else. You make it sounds like its a bug to=20 > authenticate unknown methods (mine does, btw). Its not. > > But let me pick another bad thing that can happen. > > Lets say our poor proxy is overloaded, probably from all of these PING=20= > requests. So, to quench traffic, it sends a 503 with a Retry-After,=20 > under the assumption that a compliant UAC will properly back off. But,=20= > the UAC doesn't (since UAC processing violates RFC 3261 for this=20 > method). The network continues to be overloaded with no recourse.=20 > Again, the source IP is likely to be blacklisted for non-compliance. Maybe others did, but I did not claim that the UAC needs to violate=20 RFC3261. The UAC can generate the PING and process the response for it=20= like it does for any other request. It is the server performance that=20 we worry about. > > > The flip side of this problem is a client which sends a request called=20= > PING to a server, not realizing that a spec has been produced which=20 > redefines SIP processing for tihs specific method. As such, this=20 > client is expecting normal SIP processing for this request. It hits a=20= > server which supports this "extension". This is a real issue, btw - I=20= > am aware of implementations which use the method PING. Lets say the=20 > client is using this ping for a traceroute facility. So, it sends the=20= > request with a non-zero Max-Forwards. This hits a proxy which=20 > immediately rejects it since it supports the ping "extension". Now the=20= > client is going to get incorrect information from its traceroute=20 > processing. I do not buy this argument at all. You can argue the same for any other=20= SIP request, even INVITE can be sent by a client that does not realise=20= there is a spec for it. If a UA sends a request that is standardised in=20= an RFC, it better know how to use it. If it doesn't then bad things=20 will happen, and we don't protect those clients that implement=20 proprietary extensions to sip. > > > Let us not forget that the stun mecahnism can still have a fallback to=20= > non-stun operation if the server doesnt support it. Stun messages are=20= > sent to the sip port only when the flag is present in the SIP URI=20 > indicating that the server can do the demux. We do EXACTLY this same=20= > thing with sigcomp, btw. So, if a client which supports sip outbound,=20= > has a URI for its outbound proxy which doesnt have this flag, it can=20= > resort to plain old OPTIONS with Max-Forwards: 0. No different than=20 > what happens with PING when the server doesn't support it, except we=20= > don't have the interop problems that PING will bring. Why can't we use the same flag for PING? And about sigcomp, its uncompairable. sigcomp can be viewed as a=20 wrapper. Besides, we have sipcomp and sip muxed already, how big do u=20 want your demuxer to be? Hisham > > -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 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 07 11:10:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGek6-0003vW-9H; Tue, 07 Mar 2006 11:08:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGek5-0003sa-0C for sip@ietf.org; Tue, 07 Mar 2006 11:08:57 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGek3-0000FR-Ia for sip@ietf.org; Tue, 07 Mar 2006 11:08:56 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k27G7ANE013320; Tue, 7 Mar 2006 18:07:10 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 18:08:42 +0200 Received: from localhost.localdomain ([172.21.50.42]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 7 Mar 2006 18:08:41 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k27G8eCY009513; Tue, 7 Mar 2006 18:08:40 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id k27G8d3R009512; Tue, 7 Mar 2006 18:08:39 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Thomas Froment Subject: Re: [Sip] Clarification on RFC 3261, section 10.3 =?iso-8859-15?q?=A76?= X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <440DA2FD.9020706@alcatel.fr> (Thomas Froment's message of "Tue, 07 Mar 2006 16:13:01 +0100") References: <440DA2FD.9020706@alcatel.fr> Date: Tue, 07 Mar 2006 18:08:39 +0200 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 07 Mar 2006 16:08:41.0449 (UTC) FILETIME=[66D84D90:01C64201] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "sip@ietf.org 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 Thomas Froment writes: >RFC 3261 section 10.3 (Processing REGISTER Requests) states: >part 6: >The registrar checks whether the request contains the Contact > header field. If not, it skips to the last step. If the > Contact header field is present, the registrar checks if there > is one Contact field value that contains the special value "*" > and an Expires field. If the request has additional Contact > fields or an expiration time other than zero, the request is > invalid, and the server MUST return a 400 (Invalid Request) and > skip the remaining steps. If not, the registrar checks whether > the Call-ID agrees with the value stored for each binding. If > not, it MUST remove the binding. *If it does agree, it MUST > remove the binding only if the CSeq in the request is higher > than the value stored for that binding. Otherwise, the update > MUST be aborted and the request fails.* >I am *exactly* in the last case where I MUST abort the update and "fail the request": >WHAT does exactly mean "FAIL the request": >option 1 -> should I answer error 4xx, or 5xx ? if yes, which one? >option 2-> should I just ignore the update and still answer 200 OK ? You get there when registrar has already seen a REGISTER request with same Call-ID but higher CSeq, so I'd choose option 1 and return 400 Reordered or something. >This test case is performed in ETSI RFC 3261 test suite, and this >test suite assume option 2 is correct, but it does not seem so >clear reading RFC... --Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 07 11:58:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfTq-0008Ob-GT; Tue, 07 Mar 2006 11:56:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfTp-0008Lz-BT for sip@ietf.org; Tue, 07 Mar 2006 11:56:13 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGfTp-0001wm-45 for sip@ietf.org; Tue, 07 Mar 2006 11:56:13 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k27Gu8jS019748; Tue, 7 Mar 2006 11:56:12 -0500 (EST) From: "Brett Tate" To: "'Samir Srivastava'" Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING request processing? Date: Tue, 7 Mar 2006 11:57:11 -0500 Message-ID: <000f01c64208$2de1eb70$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60ABC5B25@zrc2hxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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'm not aware of much distinction among the proposals. >=20 > The SIP 503 response works ok. And after=20 > draft-rosenberg-sipping-overload-reqs is resolved; hopefully=20 > the 503 response (or alternate solution) will work better. >=20 > The "double CRLF" and STUN mechanisms would likely cause less=20 > overload. And if an overload causes the connection/binding to=20 > be suspect, the subsequent SIP request could trigger a 503=20 > when needed. >=20 > SS>> We need to wait for Next Register Refresh, INVITE or=20 > other SIPrequest. And then do 503 for it. Will it not be=20 > too late to stop CRLF ?=20 It depends upon how the "double CRLF" mechanism is defined. I assume = the number of tries before the connection/binding is suspect would be = similar to using a SIP message mechanism (over connection oriented transport). And depending upon what needs to occur when the connection/binding is = suspect, all solutions might require a subsequent REGISTER (and hopefully none or limited "retargeting" required when dialogs exist). The evaluation would likely have to consider things like the following: 1) What are the ramifications of returning a 503? (draft-rosenberg-sipping-overload-reqs presents some of the current problems/limitations with sending a 503.) 2) What is the typical retry-after value returned when in overload (especially when returning a 503)? 3) What is the likely device overloaded and why? What is the trade off = cost of receiving, decoding, and replying with a SIP 503 versus receiving, decoding, and replying using the "double CRLF" mechanism? 4) How many "double CRLF" and/or SIP request are sent before deeming the connection/binding suspect? And for the SIP messaging, is packet fragmentation likely within the connection? > IMHO, load is caused by CRLF and it should be stopped=20 > there with the response. See above. > STUN doesn't have mechanism for Retry-After as per 3489,=20 > so SIP PING with 503 is better in this case. Or add this=20 > logic in STUN-bis ? The SIP request solution has both the benefit and curse of sharing the = SIP overload solutions (503 with retry-after and solution of draft-rosenberg-sipping-overload-reqs). And it has the benefit of potentially using a 500 with retry-after for usage when the mechanisms interval can potentially be extended a little without it impacting other dialogs and requests. I still have no strong opinion concerning what to use over UDP. STUN = and the sip request solutions both have their advantages and disadvantages. = And STUN is potentially a little better if most worried about the capacity = of the devices/pipes between the 2 SIP devices. For connection oriented transports, the "double CRLF" appears to be the = most efficient if it reasonably satisfies the requirements. And it would be nice to document and/or define some recommended = solutions for use when the "double CRLF" and STUN mechanisms (if chosen) are not supported by one or both of the devices. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 07 12:19:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfox-0001I6-TW; Tue, 07 Mar 2006 12:18:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfov-0001HB-R6 for sip@ietf.org; Tue, 07 Mar 2006 12:18:01 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGfov-0002t7-D9 for sip@ietf.org; Tue, 07 Mar 2006 12:18:01 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k27HHwfg005662; Tue, 7 Mar 2006 19:17:59 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 19:17:59 +0200 Received: from localhost.localdomain ([172.21.50.42]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 7 Mar 2006 19:17:58 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k27HHvY2010137; Tue, 7 Mar 2006 19:17:57 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id k27HHvnq010136; Tue, 7 Mar 2006 19:17:57 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Jonathan Rosenberg Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <440C9DF1.8080401@cisco.com> (Jonathan Rosenberg's message of "Mon, 06 Mar 2006 15:39:13 -0500") References: <62B9B0847CC47543B6B3B5E26BD268E60ABC55EE@zrc2hxm2.corp.nortel.com> <440C9DF1.8080401@cisco.com> Date: Tue, 07 Mar 2006 19:17:56 +0200 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 07 Mar 2006 17:17:58.0630 (UTC) FILETIME=[14B7C860:01C6420B] 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 Jonathan Rosenberg writes: >The flip side of this problem is a client which sends a request called PING >to a server, not realizing that a spec has been produced which redefines SIP >processing for tihs specific method. As such, this client is expecting >normal SIP processing for this request. It hits a server which supports this >"extension". This is a real issue, btw - I am aware of implementations which >use the method PING. Lets say the client is using this ping for a traceroute >facility. So, it sends the request with a non-zero Max-Forwards. This hits a >proxy which immediately rejects it since it supports the ping "extension". >Now the client is going to get incorrect information from its traceroute >processing. >Let us not forget that the stun mecahnism can still have a fallback to >non-stun operation if the server doesnt support it. Stun messages are sent >to the sip port only when the flag is present in the SIP URI indicating that >the server can do the demux. We do EXACTLY this same thing with sigcomp, >btw. So, if a client which supports sip outbound, has a URI for its outbound >proxy which doesnt have this flag, it can resort to plain old OPTIONS with >Max-Forwards: 0. So, you are proposing that (unless it has been provisioned with outbound proxy URI containing param "sip-stun"), client sends 1) OPTIONS with Max-Forwards: 0, 2) gets the set of outbound proxy uris in the Contact header of the response., 3a) checks from the URI list if proxy supports sip-stun and/or sigcomp or the favourite refresh method of the month, or 3b) if there is no URI in response to OPTIONS, client defaults to OPTIONS with Max-Forwards: 0? BTW, how do you propose we should combine SigComp and STUN over TCP? I suppose we have to send STUN inside SigComp, because RoHC people did not want to have protocol interleaving with SigComp, but could a client just reuse the stun transaction id? That would mean that neither client nor server have to compress/decompress each STUN message. --Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 07 12:26:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfv2-0008BB-E0; Tue, 07 Mar 2006 12:24:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfv1-0008B6-39 for sip@ietf.org; Tue, 07 Mar 2006 12:24:19 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGfuz-00032Y-Si for sip@ietf.org; Tue, 07 Mar 2006 12:24:19 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id A123F6C022 for ; Tue, 7 Mar 2006 12:24:17 -0500 (EST) Subject: Re: [Sip] Clarification on RFC 3261, section 10.3 =?ISO-8859-1?Q?=A76?= From: "Dale R. Worley" To: Sip In-Reply-To: <440DA2FD.9020706@alcatel.fr> References: <440DA2FD.9020706@alcatel.fr> Content-Type: text/plain Date: Tue, 07 Mar 2006 12:24:17 -0500 Message-Id: <1141752257.20503.9.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 On Tue, 2006-03-07 at 16:13 +0100, Thomas Froment wrote: > Otherwise, the update > MUST be aborted and the request fails.* > > I am *exactly* in the last case where I MUST abort the update and > "fail the request": > WHAT does exactly mean "FAIL the request": > > option 1 -> should I answer error 4xx, or 5xx ? if yes, which one? > option 2-> should I just ignore the update and still answer 200 OK ? > > This test case is performed in ETSI RFC 3261 test suite, and this test > suite assume option 2 is correct, but it does not > seem so clear reading RFC... It would be extremely odd to "fail the request" by sending "200 OK". Generally, an out-of-order request is rejected with a 500 response (see 12.2.2), but I personally don't like that, as it is not a failure of the server, but rather of the response. We should define a particular 49x code for that. 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 Tue Mar 07 12:30:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfyq-0002LE-8F; Tue, 07 Mar 2006 12:28:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfyp-0002L9-Jc for sip@ietf.org; Tue, 07 Mar 2006 12:28:15 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGfyo-0003Bn-9O for sip@ietf.org; Tue, 07 Mar 2006 12:28:15 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k27HSIpQ012538 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 7 Mar 2006 11:28:20 -0600 In-Reply-To: <17421.9824.795536.273253@rautu.tutpro.com> References: <62B9B0847CC47543B6B3B5E26BD268E60ABC59D0@zrc2hxm2.corp.nortel.com> <17421.9824.795536.273253@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1796D498-0F68-43F6-AC2D-A161843AC605@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Date: Tue, 7 Mar 2006 11:27:57 -0600 To: Juha Heinanen X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, Michael Procter , "Bharrat, Shaun" , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 7, 2006, at 12:21 AM, Juha Heinanen wrote: > > this goes too far. you must have lived to long in bell-head > world. as > i told before, proxies route sip requests. if you want to charge for > that, it doesn't matter if request is INVITE or NON-INVITE. I will note, I think I've seen a correlation between people who believe you can bill from signaling as seen by proxies, people who think edge proxies are all b2buas and/or SBCs, people who think we should specify a finite set of standardized services, and people who worked in traditional PSTN environments long enough to get comfy there. Not 100%, but still a high correlation. I think this does point at a very deep philosophical divide within our community. -- 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 Mar 07 12:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGg5d-00008a-Gl; Tue, 07 Mar 2006 12:35:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGg5b-00007k-OL for sip@ietf.org; Tue, 07 Mar 2006 12:35:15 -0500 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGg5Z-0003Sa-Jm for sip@ietf.org; Tue, 07 Mar 2006 12:35:15 -0500 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k27HZCvw022918; Tue, 7 Mar 2006 18:35:12 +0100 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id k27HZ9sY027468; Tue, 7 Mar 2006 18:35:09 +0100 Message-ID: <440DC452.6000000@alcatel.fr> Date: Tue, 07 Mar 2006 18:35:14 +0100 From: Thomas Froment Organization: Alcatel User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" Subject: =?ISO-8859-1?Q?Re=3A_=5BSip=5D_Clarification_on_RFC_32?= =?ISO-8859-1?Q?61=2C_section_10=2E3_=A76?= References: <440DA2FD.9020706@alcatel.fr> <1141752257.20503.9.camel@cdhcp139.pingtel.com> In-Reply-To: <1141752257.20503.9.camel@cdhcp139.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 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 Dale R. Worley wrote: >On Tue, 2006-03-07 at 16:13 +0100, Thomas Froment wrote: > > >> Otherwise, the update >> MUST be aborted and the request fails.* >> >>I am *exactly* in the last case where I MUST abort the update and >>"fail the request": >>WHAT does exactly mean "FAIL the request": >> >>option 1 -> should I answer error 4xx, or 5xx ? if yes, which one? >>option 2-> should I just ignore the update and still answer 200 OK ? >> >>This test case is performed in ETSI RFC 3261 test suite, and this test >>suite assume option 2 is correct, but it does not >>seem so clear reading RFC... >> >> > >It would be extremely odd to "fail the request" by sending "200 OK". > > I agree with you this is somewhat strange, but we can imagine a registrar just "ignore" an update and should fail the "update request",but not the "SIP request" -> that means it will answer 200 OK with the same number of bindings as previously, and this could be considered as a way to "fail the request". At least, it seems to be the way the ETSI SIP compliance TTCN test is coded, and people having specified this test have interpreted (or misinterpreted) things like this... I would be happy, if one of them is in the list, could answer... >Generally, an out-of-order request is rejected with a 500 response (see >12.2.2), but I personally don't like that, as it is not a failure of the >server, but rather of the response. We should define a particular 49x >code for that. > > Yes, but this is a more general question... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 07 12:57:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgPo-000877-Sx; Tue, 07 Mar 2006 12:56:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgPn-00080e-4Y for sip@ietf.org; Tue, 07 Mar 2006 12:56:07 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGgPl-0004Ku-UY for sip@ietf.org; Tue, 07 Mar 2006 12:56:07 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 9AD136C022 for ; Tue, 7 Mar 2006 12:56:05 -0500 (EST) Subject: Re: [Sip] Clarification on RFC 3261, section 10.3 =?ISO-8859-1?Q?=A76?= From: "Dale R. Worley" To: Sip In-Reply-To: <440DC452.6000000@alcatel.fr> References: <440DA2FD.9020706@alcatel.fr> <1141752257.20503.9.camel@cdhcp139.pingtel.com> <440DC452.6000000@alcatel.fr> Content-Type: text/plain Date: Tue, 07 Mar 2006 12:56:05 -0500 Message-Id: <1141754165.20503.12.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: sip@ietf.org X-Mailman-Version: 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, 2006-03-07 at 18:35 +0100, Thomas Froment wrote: > I agree with you this is somewhat strange, but we can imagine a > registrar just "ignore" an update > and should fail the "update request",but not the "SIP request" -> that > means it will answer 200 OK with the same > number of bindings as previously, and this could be considered as a way > to "fail the request". I would think that if the authors of 3261 wished to allow that, they would have used the verb "ignore". > At least, it seems to be the way the ETSI SIP compliance TTCN test is > coded, and people having specified this test > have interpreted (or misinterpreted) things like this... I wouldn't be surprised if ETSI has made a mistake in their test suite. 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 Tue Mar 07 13:59:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGhNn-0001MT-AO; Tue, 07 Mar 2006 13:58:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGhNl-0001Hl-Q5 for sip@ietf.org; Tue, 07 Mar 2006 13:58:05 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGgcb-0004vg-Td for sip@ietf.org; Tue, 07 Mar 2006 13:09:21 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGgO8-0007kJ-Tm for sip@ietf.org; Tue, 07 Mar 2006 12:54:25 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k27HsdfO012664 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 7 Mar 2006 11:54:40 -0600 In-Reply-To: <1141718155.10301.14.camel@eeek.ingate.se> References: <1141718155.10301.14.camel@eeek.ingate.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <37FFEC27-3672-4AE7-B4A5-7E003C45B797@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 Date: Tue, 7 Mar 2006 11:54:18 -0600 To: Hans Persson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -2.4 (--) 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 On Mar 7, 2006, at 1:55 AM, Hans Persson wrote: > I just went back and had a look at draft-ietf-sip-identity-06. As =20 > far as > I can see, an Identity header really says two things at the same time. > 1) The sender is who he claims to be. 2) The message looks like it did > when it was sent. > > Both these functions are nice in an ideal world, but many people will > have SBCs, B2BUAs, or SIP-aware firewalls in their call paths. These > will modify SDP and probably the Contact header. > > As far as I can see there is no discussion in the draft about this at > all, apart from the probably na=C4=A9ve assumption that it shouldn't =20= > happen. That's because IT SHOULDN'T HAPPEN. A B2BUA is NOT A proxy, and is NOT, in general, identity-transparent If you put a B2BUA in the loop, all that SIP Identity can really give =20= you is an assertion about a request's state when it left the B2BUA, =20 because for all practical purposes that is the originating UA for the =20= request. It's a UA. It might have another protocol or a user =20 interface on the other side of it instead of SIP, and the Identity =20 mechanism can't tell the difference. Consequently, it is up the B2BUA implementor to work with the =20 identity-asserting operator in question and establish themselves as =20 valid identity sources within the framework of that operator, and not =20= as the man-in-the-middle attacks that they would otherwise appear to be. -- 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 Mar 07 16:00:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjFw-0002bE-8Y; Tue, 07 Mar 2006 15:58:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGj88-0000ra-8J; Tue, 07 Mar 2006 15:50:04 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGj86-000230-UY; Tue, 07 Mar 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k27Ko20e024723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGj86-0001Bx-AH; Tue, 07 Mar 2006 15:50:02 -0500 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, 07 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-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 : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-02.txt Pages : 31 Date : 2006-3-7 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. Even when a proxy server can open a TCP connection to a User Agent, most User Agents lack a certificate suitable to act as a TLS (Transport Layer Security) server. 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-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-outbound-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-outbound-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: <2006-3-7123420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7123420.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 Mar 07 17:36:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGkkv-00080x-QY; Tue, 07 Mar 2006 17:34:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGkkt-0007vo-4p; Tue, 07 Mar 2006 17:34:11 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGkkr-0006R6-QF; Tue, 07 Mar 2006 17:34:11 -0500 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k27MY1nV048617 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 7 Mar 2006 16:34:02 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> References: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <737A9826-2F96-4F1C-95D6-4AEA17F9DB2E@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] SIPIT 18 Registration is open Date: Tue, 7 Mar 2006 16:34:00 -0600 To: Robert Sparks X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (shaman.nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "sip@ietf.org WG" , sip-implementors@cs.columbia.edu, Sipping WG , "simple@ietf.org 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 Reminder: Registration for SIPIT 18 closes in 3 weeks. If you are planning to attend and have not yet registered, please do so now. Thanks, RjS On Feb 6, 2006, at 11:42 PM, Robert Sparks wrote: > Registration for SIPit 18 is open. > > This event will be held April 17-21 in > Akihabara, Tokyo, Japan. More information > about the event is available at http://www.sipit.net > and the host website at http://www.nic.ad.jp/en/sipit18/ > > Registration will close March 31. Please register early. > You can register now using https://www.regonline.com/88905 > > This 18th SIPForum SIPit is > > Hosted by: > - Japan Network Information Center (JPNIC) > > Co-hosted by: > - WIDE Project > - VoIP System Interoperability Task Force > > Supported by: > - Ministry of Internal Affairs and Communications (MIC) > - The Telecommunication Technology Committee (TTC) > - Telecom Service Association (TELESA) > - VoIP Forum Japan (VFJ) > - IPv6 Promotion Council (v6PC) > - ENUM Trial Japan (ETJP) > > Sponsors: > - Cisco Systems, Inc. > - Fractalist Inc. > - Fusion Communications Corporation > - Japan Telecom Co., Ltd. > - KDDI Corporation > - Mitsubishi Electric Information Network Corporation > - Mitsubishi Research Institute, Inc. > - NEC Corporation > - Netmarks Inc. > - Nippon Telegraph and Telephone Corporation > - Nippon Telegraph and Telephone East Corporation > - Nippon Telegraph and Telephone West Corporation > - NTT Advanced Technology Corporation > - Oki Electric Industry Co., Ltd. > - SoftBank BB Corp. > - Softfront > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 07 20:41:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGnds-0003Sn-BO; Tue, 07 Mar 2006 20:39:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGndq-0003Si-I6 for sip@ietf.org; Tue, 07 Mar 2006 20:39:06 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGndp-0007J3-4w for sip@ietf.org; Tue, 07 Mar 2006 20:39:06 -0500 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 k281cul29542; Tue, 7 Mar 2006 20:38:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Date: Tue, 7 Mar 2006 19:38:54 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF07728E54@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processing fasterthan a SIP PING requestprocessing? Thread-Index: AcZBUCqLH5yxq+LORrSfPqvU6rDCBAA/q4pg From: "Francois Audet" To: "Jonathan Rosenberg" , "Michael Procter" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: sip@ietf.org, "Bharrat, Shaun" , Alan Duric , Dusan Stevanovic X-BeenThere: sip@ietf.org X-Mailman-Version: 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 point is not really backward compatibility. The point is that I can=20 choose to implement this using NORMAL SIP. What it allows me to do, if I am not concerned about optimizing the PING processing as Hisham's, is to implement this on a SIP PING server (which may or may not be the edge proxy). I can just treat it as a new method with processing that happens to be quite simple (i.e., I can 200 it).=20 If I am an "Enterprise" SIP vendor, and I'm doing a simple SIP product, I can implement this in no time. Since the scale is small, there is no reason to "optimize" the PING method processing. Not every SIP implementation in the world is going to be a massive SIP service provider. Lot's of people out there will have smaller scale offering. If on the other hand, I am doing a large scale SIP offering, and I need to keep the keep-alive very liteweight, then I can do exactly what Hisham has=20 demonstrated.=20 I will note that we have also implemented the same idea in real live large-scale systems and have found that PING processing to be minimal. I'm glad to see that Hisham proved the same thing. On the client side, there is also an advantage that it is trivial to implement. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Monday, March 06, 2006 10:59 > To: Michael Procter > Cc: sip@ietf.org; Bharrat, Shaun; Alan Duric; Dusan Stevanovic > Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request=20 > processing fasterthan a SIP PING requestprocessing? >=20 >=20 > inline. >=20 > Michael Procter wrote: >=20 > > Bharrat, Shaun wrote: > >=20 > >>Now that I understand what is actually being done, I guess > >>my question is why you would have expected the numbers to > >>be any different? > >=20 > > [...] > >=20 > >>If we are "allowed" to skip the SIP processing (i.e. it's > >>not really a SIP packet), then I agree that we can make the=20 > processing=20 > >>time of a PING arbitrarily close to a STUN packet=20 > processing. However,=20 > >>if we are not, I don't agree that this is a valid comparison of a=20 > >>SIP-based keepalive versus a STUN based keepalive. > >=20 > >=20 > > I think the point is that the message has sufficient SIP=20 > headers that=20 > > it can be parsed and rejected (501) by a stack that doesn't support=20 > > the extension. A rejection is an acceptable response to the PING=20 > > request, > >=20 > > So, the PING request is in some sense backwards-compatible with=20 > > existing code. >=20 > Thats my beef with this whole thing. That its "in some sense"=20 > backwards=20 > compatible, but not really. >=20 > You are taking something that LOOKS like SIP, but is=20 > fundamentally NOT=20 > SIP, and sending to a server in the hopes that the right=20 > thing happens.=20 > However, in the real world, odd things will always happen.=20 > Let me give=20 > some examples. >=20 > UAC sends the PING request to its proxy. Proxy doesnt support=20 > the method=20 > but forwards it on to another proxy, ignorning max-forwards (some=20 > elements do this, as they serve as 'fronts' to the real=20 > proxy). Packet=20 > is lost. Well, you've changed the retransmit rules for PING=20 > from normal=20 > SIP, and there are no retransmits. So, there is a timeout.=20 > We'll have a=20 > nice race condition, first of all, since the outbound proxy, having=20 > thought this was normal SIP, will generate a 408 at some point, but=20 > probably after the UAC gives up. Depends on how you define=20 > your new PING=20 > protocol transaction timers relative to real sip. Assuming=20 > though that=20 > the UAC times out first, the UAC will think that its proxy is=20 > down, but=20 > its not. Seems really bad to me. >=20 > Here's another funny case. PING goes to a proxy, which doesn't know=20 > about PING, but wants to authenticate the request. So, it=20 > responds with=20 > a 401 and challenges the request. Well, you might say it=20 > worked fine -=20 > nat binding kept alive. However, many proxies will set off=20 > alarms with=20 > their intrusion detection systems on repeated 401 messages=20 > from the same=20 > source IP, so your client may find itself banned from the=20 > network pretty=20 > quickly. >=20 > Both of these problems can be fixed by putting Proxy-Require=20 > and Require=20 > in. However, that defeats the whole point of this mechanism, to be=20 > "backwards compatible" with existing SIP. So, if you do that, may as=20 > well use STUN. >=20 > So, to be clear, I think that this whole idea of something that looks=20 > like SIP, but isn't, in the supposed hopes of being "backwards=20 > compatible" with existing equipment, is a big, big mistake, and will=20 > result in all kinds of unpredicable and really hard to debug=20 > problems in=20 > the real world. >=20 >=20 >=20 > Of course, newer implementations may choose to > > optimise the processing for it, so that they can get=20 > performance that=20 > > is equivalent to STUN, but there is no need to do so for=20 > the feature=20 > > to work. Implementing the fast-path processing is=20 > therefore purely an=20 > > implementation issue, not a protocol compliance issue. >=20 > Wrong, as I have pointed out. As soon as you make a change=20 > that alters=20 > MUST-strength processing in clients (as the PING method has),=20 > you have=20 > introduced interoperability problems. >=20 > -Jonathan R. >=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 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > 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 Mar 07 22:27:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGpJ1-0006cK-8k; Tue, 07 Mar 2006 22:25:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGpIz-0006br-IL for sip@ietf.org; Tue, 07 Mar 2006 22:25:41 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGpIu-0002Gs-2h for sip@ietf.org; Tue, 07 Mar 2006 22:25:41 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVS00MNCI051T@szxga02-in.huawei.com> for sip@ietf.org; Wed, 08 Mar 2006 11:36:05 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVS00DYFI03ZB@szxga02-in.huawei.com> for sip@ietf.org; Wed, 08 Mar 2006 11:36:05 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IVS00MIPHZR06@szxml02-in.huawei.com>; Wed, 08 Mar 2006 11:35:54 +0800 (CST) Date: Wed, 08 Mar 2006 11:23:02 +0800 From: Xiao Wang Subject: RE: [Sip] Re: Dialog usage: Forking impacts In-reply-to: <44085FF0.3000200@cisco.com> To: 'Paul Kyzivat' , christer.holmberg@ericsson.com Message-id: <02e401c6425f$9b95f420$b2b04c0a@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=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcY+1r9MxQokdi/VRmac3UoSTnEeDgDh0eag X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 think that reuse early dialog may be risk. Because SUBSCRIBE may arrive at UA1 before 1xx or 2xx for the reason of net delay or lose, so UA1 doesn't find out a match dialog for SUBSCRIBE, finally the SUBSCRIBE will be dropped, and return 400. Xiao > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, March 03, 2006 11:26 PM > To: Christer Holmberg (JO/LMF) > Cc: IETF SIP List > Subject: [Sip] Re: Dialog usage: Forking impacts > > > > Christer Holmberg (JO/LMF) wrote: > > > > Hi, > > > > Another scenario related to the dialog usage issue: > > > > 1. UA_1 sends an INVITE, which gets forked to UA_2 and UA_3. > > > > 2. UA_2 establish an early dialog with UA_1 and sends a SUBSCRIBE > > (or any other request establishing a new dialog usage) to UA_1, > > establishing a dialog usage (subscribe dialog usage in case of SUBSCRIBE). > > > > 3. UA_3 acceptes the session for the INVITE and sends 200 OK (INVITE) > > > > 4. The forking proxy sends a CANCEL to UA_2, and forwards the 200 > > OK (INVITE) to UA_1. > > > > 5. UA_1, when receiving the 200 OK, would normally terminate the > > early dialog between itself and UA_2. BUT, in this case it can't do it, > > because it still has an active subscription dialog usage association > > with UA_2, and the CANCEL sent by the proxy didn't terminate that dialog > > usage in UA_2 either. > > This does point up some issues with language in the RFCs. I doubt there > really is any such thing as an "early dialog". In reality there is only > one kind of dialog, but there is an "early invite dialog usage". > > > Now, the dialog usages still share the same dialog, but from the UA_1 > > perspective each dialog usage has DIFFERENT route sets and remote targets... > > Don't think I agree. Following step 3, or maybe sooner, UA1 knows there > are two dialogs, because it has received responses with different > to-tags. The early invite dialog usage with UA2 and the subscribe from > UA2 share one dialog, and the invite dialog usage with UA3 uses the > other dialog. > > There isn't anything new here due to sharing. UA2 and UA3 could have > both established early invite dialog usages. UA1 has to deal with two > dialogs in that case as well. > > The key thing in all this is that the lifetime of dialogs is not > explicitly managed. Rather it is reference counted based on the usages > that share it. > > > Saying that dialog re-usage is only allowed for FULLY ESTABLISHED > > dialogs would of course solve this, but currentely I think it's legal > > from a pure SIP perspective. Or? > > This is one of the reasons why I think it is a bad idea to start putting > restrictions on the use of shared dialogs. As things stand, the whole > ediface does tie together using just a few basic principles. If you > support those principles, then all the different possible combinations > of usages will work. If you impose restrictions on the kinds of usages > that are allowed, you encourage implementations that implement all sorts > of special case logic. Figuring out what special case logic is > sufficient is harder than implementing the general case. > > Paul > > > 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 Mar 07 23:19:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGq6y-0002ql-VJ; Tue, 07 Mar 2006 23:17:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGq6x-0002kI-7K for sip@ietf.org; Tue, 07 Mar 2006 23:17:19 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGq6w-0004D6-VB for sip@ietf.org; Tue, 07 Mar 2006 23:17:19 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 8A3DD6C017 for ; Tue, 7 Mar 2006 23:17:18 -0500 (EST) Subject: Re: [Sip] Re: Dialog usage: Forking impacts From: "Dale R. Worley" To: Sip In-Reply-To: <440CC3CC.1020003@cisco.com> References: <440CC3CC.1020003@cisco.com> Content-Type: text/plain Date: Tue, 07 Mar 2006 23:17:18 -0500 Message-Id: <1141791438.24046.23.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mon, 2006-03-06 at 18:20 -0500, Paul Kyzivat wrote: > The way I think of it is 3261 did, at least implicitly, define both the > concept of the dialog and the dialog usage, as distinct things. But it > inadvertently gave them both the same name. Sometimes it uses that name > to talk about dialogs, and other times to talk about dialog usages. The > reader is left to sort out the ambiguity. I would say it a bit differently: The writers of 3261 didn't fully conceptualize the distinction between dialog and dialog usage, and used the same word for both. We are now realizing that the distinction needs to be made, and have to sort out the ambiguities in the original text. The evidence that we are doing this correctly is that we can construct a simple model (a dialog is a bundle of dialog usages, whose existence is implicitly controlled by the existence of the usages) and that when 3261 is disambiguated in the light of that model: 1) the logic of the protocol remains fairly simple, 2) lots of messy edge cases "just work out" to give the results you'd really want in the first place, and 3) it provides a clean, systematic framework for almost any imaginable extension of the current "shared usage" situation. However, there is one nit that needs to be dealt with, I think. Since messages can be reordered by the network, a UA can see the termination of the last usage that it knows of in a dialog (e.g., receiving the 200 for a BYE) before it receives the initiation of another usage (e.g., receiving a SUBSCRIBE), while the other UA may have sent the SUBSCRIBE before receiving the BYE. So whether there are any usages of a dialog active at a moment is not knowable by a UA. This means that the dialog state (the route set and the CSseq's) has to be kept around for a while after the UA thinks the dialog has ended. Does there need to be a timer for disposing of this information? Or can we sleaze it by having the SUBSCRIBE re-establish the dialog state at the other UA? I don't think that works, as the sender of the SUBSCRIBE expects the NOTIFYs to have CSeq's that continue from whatever it last received, so the UAS for the SUBSCRIBE must not have thrown away its state for that dialog. So I think we need to define a timer, "length of time after the termination of the last dialog usage you know of in a dialog that you can start a new usage" (probably 0), and "length of time after the termination of the last dialog usage you know of in a dialog that you can safely delete your dialog state information" (3 minutes?). 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 Tue Mar 07 23:34:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGqLW-0006XL-68; Tue, 07 Mar 2006 23:32:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGqLU-0006So-PV for sip@ietf.org; Tue, 07 Mar 2006 23:32:20 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGqLT-0004Wy-HO for sip@ietf.org; Tue, 07 Mar 2006 23:32:20 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Mar 2006 23:32:19 -0500 X-IronPort-AV: i="4.02,174,1139202000"; d="scan'208"; a="83710475:sNHT32403440" 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 k284WJVU002748 for ; Tue, 7 Mar 2006 23:32:19 -0500 (EST) 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.211); Tue, 7 Mar 2006 23:32:19 -0500 Received: from [192.168.1.101] ([10.86.240.173]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Mar 2006 23:32:18 -0500 Message-ID: <440E5E52.20500@cisco.com> Date: Tue, 07 Mar 2006 23:32:18 -0500 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: 08 Mar 2006 04:32:18.0980 (UTC) FILETIME=[48F73E40:01C64269] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Sip] The Problem with PRACK X-BeenThere: sip@ietf.org X-Mailman-Version: 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 the last IETF, there was a lot of discussion and argument around PRACK. The spark of this debate was the ICE specification, which had words in it requiring the usage of PRACK and UPDATE in order to work with early media. There was strong pushback from many implementors that anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) that showed the state machine in his implementation resulting from PRACK, and it was not pretty. So, I'd like to discuss exactly what IS the problem with PRACK? There are really two pieces of state machinery in play here. One piece is the complication that PRACK introduces into the offer/answer model. With PRACK, you can now get a final answer in the 18x, and then send a new offer in UPDATE, or even in PRACK itself. Another piece is the state machinery with the retransmissions itself - correlating the PRACK with a particular reliable provisional response and causing it to stop. In a chat with Flemming today, he suggested in interested remedy to our PRACK dilemma. Why not revise PRACK so that you can't send an offer or answer with it; it has no impact on the set of allowed O/A exchanges defined by RFC 3261. I'm not sure if that would consequently break the preconditions mechanism, but maybe there are some kind of offer/answer limitations that would simplify things. So, this is one idea. I'd like for people who have complained about PRACK implementations to speak up and indicate what exactly makes it so complicated for them. 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 Mar 08 01:39:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGsHv-000530-Bs; Wed, 08 Mar 2006 01:36:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGsHt-0004rc-KF for sip@ietf.org; Wed, 08 Mar 2006 01:36:45 -0500 Received: from nproxy.gmail.com ([64.233.182.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGsHg-0007q7-5q for sip@ietf.org; Wed, 08 Mar 2006 01:36:45 -0500 Received: by nproxy.gmail.com with SMTP id g2so82581nfe for ; Tue, 07 Mar 2006 22:36:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ZoEOgo/yEqPG+GX4OqH+DHAt/nEDBMuG5G5ewDdjh7EJG+9G1WaCdlL7Gu6C7EHokw6sQhXuO7nb1sMjwl0VkUU7yOHpMJs8CApFakcNCTkaULwrUVVX9ualeurn5UYWIOH67aSPI18M6xzs+CnV1SgrR9UlmmR0rYCMJW0v7no= Received: by 10.48.233.6 with SMTP id f6mr172523nfh; Tue, 07 Mar 2006 22:36:30 -0800 (PST) Received: by 10.49.35.18 with HTTP; Tue, 7 Mar 2006 22:36:30 -0800 (PST) Message-ID: <52db68bc0603072236m74153a14xad7e1b0ebc03269f@mail.gmail.com> Date: Wed, 8 Mar 2006 12:06:30 +0530 From: "Sudhir Kumar Reddy" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Sip] query about torture test cases X-BeenThere: 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="===============1419982844==" Errors-To: sip-bounces@ietf.org --===============1419982844== Content-Type: multipart/alternative; boundary="----=_Part_5512_15320093.1141799790736" ------=_Part_5512_15320093.1141799790736 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All, I'm working on torture test cases. So, I would like to know about the first test case ie. "A short tortuous INVITE" which includes mutliple lines in each headers, here line includes CRLF or only \n. For inctance To Header TO : sip:vivekg@chair-dnrc.example.com ; tag =3D 1918181833n Is ToHeader value includes CRLF or \n? any feedback is appericated. thanks in advance Sudhir ------=_Part_5512_15320093.1141799790736 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi All,

I'm working on torture test cases. So, I would like to know about the fi= rst test case ie. "A short tortuous INVITE" which includes mutlip= le lines in each headers, here line includes CRLF or only \n.

For inctance To Header 
TO :
 sip:vivekg@chair-dnrc.example.com ; tag =3D= 1918181833n

Is ToHeader value includes CRLF or \n?

any feedback is appericated.


thanks in advance
Sudhir

------=_Part_5512_15320093.1141799790736-- --===============1419982844== 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 --===============1419982844==-- From sip-bounces@ietf.org Wed Mar 08 02:29:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGt4i-0004we-Vc; Wed, 08 Mar 2006 02:27:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGt4g-0004u3-T0 for sip@ietf.org; Wed, 08 Mar 2006 02:27:10 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGt4f-0001M9-5E for sip@ietf.org; Wed, 08 Mar 2006 02:27:10 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 805304F0008; Wed, 8 Mar 2006 08:26:44 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 08:26:44 +0100 Received: from [136.225.183.67] ([136.225.183.67]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 08:26:41 +0100 From: "Christer Holmberg" To: "Xiao Wang" , "Paul Kyzivat" Subject: RE: [Sip] Re: Dialog usage: Forking impacts Date: Wed, 8 Mar 2006 09:21:50 +0200 Message-ID: <4mMT1MfDWDm4.WV23cLRM@se-smtp.ericsson.se> X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Mar 2006 07:26:44.0112 (UTC) FILETIME=[A6ABA900:01C64281] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I agree with the issue you bring up. However, the "problem" already exist when subscription dialog usages are = created, because it is said that a NOTIFY may arrive before the 200 = response to the SUBSCRIBE/REFER... 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 Mar 08 02:52:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtRB-0005Pc-TB; Wed, 08 Mar 2006 02:50:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtQp-0005BE-H7; Wed, 08 Mar 2006 02:50:04 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGtQo-0001iL-0t; Wed, 08 Mar 2006 02:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k287o1BX014119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 07:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGtQn-0001cQ-Qk; Wed, 08 Mar 2006 02:50:01 -0500 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, 08 Mar 2006 02:50:01 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-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 : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy, et al. Filename : draft-ietf-sip-connect-reuse-05.txt Pages : 16 Date : 2006-3-7 When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency in environments where the connection could be opened in either direction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-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-connect-reuse-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-connect-reuse-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: <2006-3-7203912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connect-reuse-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7203912.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 Mar 08 02:52:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtR7-0005OF-Ud; Wed, 08 Mar 2006 02:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtQp-0005AV-4J; Wed, 08 Mar 2006 02:50:03 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGtQo-0001iW-Cv; Wed, 08 Mar 2006 02:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k287o2vP000420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Mar 2006 07:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGtQn-0001cz-Vp; Wed, 08 Mar 2006 02:50:01 -0500 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, 08 Mar 2006 02:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-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 : Session Initiation Protocol Location Conveyance Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sip-location-conveyance-02.txt Pages : 33 Date : 2006-3-7 This document defines how the Session Initiation Protocol (SIP) conveys, or pushes, user location information from one SIP entity to another SIP entity. SIP Location Conveyance is always end to end, but sometimes the embedded location information can be acted upon by SIP Servers to direct where the message goes, based on where the user agent client is. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-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-location-conveyance-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-location-conveyance-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: <2006-3-7205917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-location-conveyance-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-location-conveyance-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7205917.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 Mar 08 02:52:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtRB-0005Pc-TB; Wed, 08 Mar 2006 02:50:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtQp-0005BE-H7; Wed, 08 Mar 2006 02:50:04 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGtQo-0001iL-0t; Wed, 08 Mar 2006 02:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k287o1BX014119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 07:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGtQn-0001cQ-Qk; Wed, 08 Mar 2006 02:50:01 -0500 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, 08 Mar 2006 02:50:01 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-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 : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy, et al. Filename : draft-ietf-sip-connect-reuse-05.txt Pages : 16 Date : 2006-3-7 When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency in environments where the connection could be opened in either direction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-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-connect-reuse-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-connect-reuse-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: <2006-3-7203912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connect-reuse-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7203912.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 Mar 08 02:52:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtR7-0005OF-Ud; Wed, 08 Mar 2006 02:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtQp-0005AV-4J; Wed, 08 Mar 2006 02:50:03 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGtQo-0001iW-Cv; Wed, 08 Mar 2006 02:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k287o2vP000420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Mar 2006 07:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGtQn-0001cz-Vp; Wed, 08 Mar 2006 02:50:01 -0500 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, 08 Mar 2006 02:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-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 : Session Initiation Protocol Location Conveyance Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sip-location-conveyance-02.txt Pages : 33 Date : 2006-3-7 This document defines how the Session Initiation Protocol (SIP) conveys, or pushes, user location information from one SIP entity to another SIP entity. SIP Location Conveyance is always end to end, but sometimes the embedded location information can be acted upon by SIP Servers to direct where the message goes, based on where the user agent client is. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-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-location-conveyance-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-location-conveyance-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: <2006-3-7205917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-location-conveyance-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-location-conveyance-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7205917.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 Mar 08 04:01:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGuVo-00028n-MR; Wed, 08 Mar 2006 03:59:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGuVm-00021t-KR for sip@ietf.org; Wed, 08 Mar 2006 03:59:14 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGuVm-00084L-7K for sip@ietf.org; Wed, 08 Mar 2006 03:59:14 -0500 Received: (qmail 11080 invoked by uid 0); 8 Mar 2006 08:59:10 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Mar 2006 08:59:10 -0000 Message-ID: <024a01c6428e$918ffdc0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dale R. Worley" , "Sip" References: <440CC3CC.1020003@cisco.com> <1141791438.24046.23.camel@cdhcp139.pingtel.com> Subject: Re: [Sip] Re: Dialog usage: Forking impacts Date: Wed, 8 Mar 2006 09:59:11 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Dale, > However, there is one nit that needs to be dealt with, I think. Since > messages can be reordered by the network, a UA can see the termination > of the last usage that it knows of in a dialog (e.g., receiving the 200 > for a BYE) before it receives the initiation of another usage (e.g., > receiving a SUBSCRIBE), while the other UA may have sent the SUBSCRIBE > before receiving the BYE. So whether there are any usages of a dialog > active at a moment is not knowable by a UA. > I think "active usages" needs to be defined in a way that ~is~ knowable for a UA. If not, things become too complex since you cannot define logic / rules in terms of unknown state. So I would define active usages as "all usages that have state!=terminated". In the above scenario, once the first UA sends its BYE the invite usage is terminated (as per RFC4235, reading it as if "call" really means "invite-usage"). Though this has not been explicitly stated (to my knowledge), I think a UA should not accept incoming new usages when no more active usages remain in the dialog. > This means that the dialog state (the route set and the CSseq's) has to > be kept around for a while after the UA thinks the dialog has ended. > Does there need to be a timer for disposing of this information? Or can > we sleaze it by having the SUBSCRIBE re-establish the dialog state at > the other UA? I don't think that works, as the sender of the SUBSCRIBE > expects the NOTIFYs to have CSeq's that continue from whatever it last > received, so the UAS for the SUBSCRIBE must not have thrown away its > state for that dialog. > Following my line of reasoning above, the UA should refuse the new usage (I would say using a 481 response). Hence there is no need to keep the dialog state around. draft-ietf-sipping-dialogusage-01 does not make the distinction between "termination" and "destruction" (yet), I believe this remains something to be discussed. > So I think we need to define a timer, "length of time after the > termination of the last dialog usage you know of in a dialog that you > can start a new usage" (probably 0), In other words, the UA should not start (initiate) a new usage when all existing usages have terminated. I argue that it should also not accept new usages > and "length of time after the > termination of the last dialog usage you know of in a dialog that you > can safely delete your dialog state information" (3 minutes?). Here I believe we need the distinction between "termination" and "destruction" (==deletion in your wording). Usages are terminated when sending BYE, NOTIFY w/ terminated, etc. They are destroyed when a response to the "termination request" comes back, or when there is a timeout. The dialog is considered terminated ( "ended" in your text above ) when all usages are terminated, i.e. termination requests have been sent / received for all of them. The dialog is destroyed after the last usage has been destroyed (in other words: when there are no more active transactions). There would be no need for a separate timer, all of the above is done using the regular transaction timers. 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 Mar 08 04:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGvL8-0007Nc-3t; Wed, 08 Mar 2006 04:52:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGvL6-0007NX-14 for sip@ietf.org; Wed, 08 Mar 2006 04:52:16 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGvKg-00027z-No for sip@ietf.org; Wed, 08 Mar 2006 04:52:16 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVS00I74Z5Y7I@szxga03-in.huawei.com> for sip@ietf.org; Wed, 08 Mar 2006 17:46:46 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVS00KCBZ5YQ9@szxga03-in.huawei.com> for sip@ietf.org; Wed, 08 Mar 2006 17:46:46 +0800 (CST) Received: from z53160 ([10.164.55.79]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IVS003DSZF4R9@szxml02-in.huawei.com>; Wed, 08 Mar 2006 17:52:17 +0800 (CST) Date: Wed, 08 Mar 2006 17:39:27 +0800 From: Zhou Hong Subject: Re: [Sip] Re: Dialog usage: Forking impacts To: "Dale R. Worley" Message-id: <003001c64294$313ad4d0$4f37a40a@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 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1141791438.24046.23.camel@cdhcp139.pingtel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 think maybe we can define a new dialog state Zombie before state Terminated. in this state not receive and deal with any new dialog usages,otherwise terminate all old dialog usages. The dialog state change to Terminated when all dialog usages finished. Hong ----- Original Message ----- From: "Dale R. Worley" To: "Sip" Sent: Wednesday, March 08, 2006 5:38 PM Subject: Re: [Sip] Re: Dialog usage: Forking impacts > On Mon, 2006-03-06 at 18:20 -0500, Paul Kyzivat wrote: >> The way I think of it is 3261 did, at least implicitly, define both the >> concept of the dialog and the dialog usage, as distinct things. But it >> inadvertently gave them both the same name. Sometimes it uses that name >> to talk about dialogs, and other times to talk about dialog usages. The >> reader is left to sort out the ambiguity. > > I would say it a bit differently: The writers of 3261 didn't fully > conceptualize the distinction between dialog and dialog usage, and used > the same word for both. We are now realizing that the distinction needs > to be made, and have to sort out the ambiguities in the original text. > > The evidence that we are doing this correctly is that we can construct a > simple model (a dialog is a bundle of dialog usages, whose existence is > implicitly controlled by the existence of the usages) and that when 3261 > is disambiguated in the light of that model: > > 1) the logic of the protocol remains fairly simple, > 2) lots of messy edge cases "just work out" to give the results you'd > really want in the first place, and > 3) it provides a clean, systematic framework for almost any imaginable > extension of the current "shared usage" situation. > > However, there is one nit that needs to be dealt with, I think. Since > messages can be reordered by the network, a UA can see the termination > of the last usage that it knows of in a dialog (e.g., receiving the 200 > for a BYE) before it receives the initiation of another usage (e.g., > receiving a SUBSCRIBE), while the other UA may have sent the SUBSCRIBE > before receiving the BYE. So whether there are any usages of a dialog > active at a moment is not knowable by a UA. > > This means that the dialog state (the route set and the CSseq's) has to > be kept around for a while after the UA thinks the dialog has ended. > Does there need to be a timer for disposing of this information? Or can > we sleaze it by having the SUBSCRIBE re-establish the dialog state at > the other UA? I don't think that works, as the sender of the SUBSCRIBE > expects the NOTIFYs to have CSeq's that continue from whatever it last > received, so the UAS for the SUBSCRIBE must not have thrown away its > state for that dialog. > > So I think we need to define a timer, "length of time after the > termination of the last dialog usage you know of in a dialog that you > can start a new usage" (probably 0), and "length of time after the > termination of the last dialog usage you know of in a dialog that you > can safely delete your dialog state information" (3 minutes?). > > 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 Mar 08 07:20:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGxcM-0007ZF-AN; Wed, 08 Mar 2006 07:18:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGxcJ-0007Lt-Up for sip@ietf.org; Wed, 08 Mar 2006 07:18:11 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGxcH-0007Fj-Bg for sip@ietf.org; Wed, 08 Mar 2006 07:18:11 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 42F81D6D; Wed, 8 Mar 2006 13:18:06 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 13:18:05 +0100 Received: from [136.225.183.121] ([136.225.183.121]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 13:18:01 +0100 From: "Christer Holmberg" To: "Alexeitsev, D" , john.elwell@siemens.com Subject: Re: AW: [Sip] Updated connected-identity draft Date: Wed, 8 Mar 2006 14:13:10 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Mar 2006 12:18:04.0861 (UTC) FILETIME=[5A0246D0:01C642AA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org, ilan.avner@audiocodes.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Currently, you are not allowed to change the value of the To header in an = UPDATE either. >From a pure SIP protocol perspective only the tag is used for dialog = identification, so changing the "phone number" part should have no core = impacts - but some implementations may of course always check the whole = header. And, if one were allowed to change the phone number part (not only from 180 = to 200, but also in other cases), would some of the existing extension/P- = headers be made obselete? 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 Mar 08 07:45:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGy0q-0001HM-2w; Wed, 08 Mar 2006 07:43:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGy0o-0001Dv-H0 for sip@ietf.org; Wed, 08 Mar 2006 07:43:30 -0500 Received: from smtp16.clb.oleane.net ([213.56.31.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGy0n-0007zZ-Tp for sip@ietf.org; Wed, 08 Mar 2006 07:43:30 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp16.clb.oleane.net with ESMTP id k28ChFgm015820 for ; Wed, 8 Mar 2006 13:43:29 +0100 Message-Id: <200603081243.k28ChFgm015820@smtp16.clb.oleane.net> From: "Chantal Ladouce" To: Date: Wed, 8 Mar 2006 13:42:49 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZCrc7nzvTVIWs6TAa9O0Wt2/ZicQ== X-Spam-Score: 0.4 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Subject: [Sip] IMS or UMA? How to Achieve FMC? X-BeenThere: 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="===============1545320746==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1545320746== Content-Type: multipart/related; boundary="----=_NextPart_000_0142_01C642B6.310B19D0" This is a multi-part message in MIME format. ------=_NextPart_000_0142_01C642B6.310B19D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0143_01C642B6.310B19D0" ------=_NextPart_001_0143_01C642B6.310B19D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IMS or UMA? How to Achieve FMC? At the 2006 Wireless/WiFi Convergence Conference to be held in Paris on May 16 to May 19, distinguished experts and key players in the convergence field will address technical issues. Moreover, carriers like BT, Orange, Vonage (etc) will discuss their commercial experience and technological choices. Get all details at: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006intro.htm ------=_NextPart_001_0143_01C642B6.310B19D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMS or UMA?

How to Achieve FMC?

 

At the 2006 Wireless/WiFi Convergence Conference to be held in Paris on May 16 to May = 19,

distinguished experts and key players in the convergence field will address technical issues. =

Moreover, carriers like BT, Orange, Vonage (etc) will discuss = their commercial experience and

    &nb= sp;  technological choices.

 

    &nb= sp; Get all details at:

    &nb= sp; http://www.upperside.fr/wirelessconvergence2006/wwconvergence= 2006intro.htm

 

 

------=_NextPart_001_0143_01C642B6.310B19D0-- ------=_NextPart_000_0142_01C642B6.310B19D0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAArAJUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDzYFiT 1pPJmbpmvdvDfhrw9rnha2vRpdv5s0OGZR0fGD+teUXKxWV3PbSKN8MhTH0OKR9RhFTxMpQk7cpz 7WkjDqadHpsrHoa+gNB8GaQNCszd6fE87RhnZhzk815Z4uiXQPEt3YrGERW3xjH8J6UWJw8sJVqu Ddrfic5Ho7nrXs/wjt/s3hmeLv8AaCf0FQfDzw9Yan4YTUNQtEledyULDoo4FYera1Z2fli0vbvT bf8AtVoEWyAw+NoO7PbOaaObH1sNKEqdGL06nsApa4jWPidpuia7caLJY31xdQoCogj3+YcZ4xTb X4q6HN4autbkiuIRayiKS3ZcuXPQD8qDwjuaK89PxatbcQTahod/Z2s7AJO+1hz7A1VfXL8/GiGy S/lOntZ+b5Ib5Mbc5xQB6ZRXnw+LFtcSXB03Q7+9gt2KvOm0DjqcGrM/xU0KHwtHr+y4aOSYwCHb 84cDJB/CgDuKQjNcCnxSUPD9p8OalBHMQFcBX6+wNW9e+JFjo2uLo0On3V7eMgcxxYXAIz39qAOx JA61k3XibRLKcxXWpW8TrwVLdKx9H8eR63ey6c+kX1jOsZcGVQU4H94dKy/h/o2m6nZ311e2kdxK 1yw3OM8ZpnXQo05U5VKl7Lt5nb2epWN/CZrO6jmjXqUbgVRk8WaBFKYn1W3D5xjdXEWqjTNS8WWt oPLiS3LIqnAHNQ6Je6Jb+HUin0Ce8co3nTpDnBOehpHasvhq9WtNrX1Vz1K3uIrqES28iyxt0ZTk GisHwOmnR+H1/sqeWWBnJ/fH5kPpRQeXWgqdRwXTuct8F9U8/Sb3THYlraXegPo3/wBeuc8SeHHn +L8enxgiK9mSc+m3qf1Bql8KtU/s7xrDCxxHeoYiP9rqK9mm0KGbxTb64xHmwW7QhcepzmkddWTp VW+6IdZ8RW+iatpGnOo/4mEpiH+yAOP1wK86+N+kMLzTtUiU5mzbvjueorH+KevPN48j8h+NL2hc H+MHcf6V6vfafbeNPDenSlhsLxXKn6EEigwSdPll3GxBfCnw+UkBTZWOT/vbf8a8esdPl1nw1pTC 7tYZBqzyMJ5QhfO3OM9a9D+MmqfYvCcVijYe9mC4H90cmvNtOv47HRNDSTT7a783UmAM65Kcp0oG o/unLuzukNlpvxhvdbvNW0+G2EHlYaYb1bA4xUvjW28M+KdBk03QdW0yG/nuFlCrIB5z+hx3rz7W n0yL4raw2raXPqVv5rfuLc4bOBg1v+HpvBlz4hsYLfwXqdtM8y7JpHO2Ns8E0zmIrfwve62iabY6 DpQuLVwtzMb9pduOCSmeO9dgfBmqf8LKh1fy4xp6WX2curcg7NvSsTwp4hNnd+Lbq20yzgntpAoa NcbyXIBb19a7aK613TWjvdSvbe5sPKL3DCPYY+M8etBtCg5R5rnntp8Odc0Z7u3/AOEdttXWSQtF cG9aLAPqoNah8Aa0ngJtNGm6W93Jdmdrfc21Vxxhs/ersl8a2Cwyyz29zDsjEqq6cuhOAR+YqRPF 9i0yxSQ3ELmRIysiYI3fdP0oH9Wqv7J5fdfDvxLdJDHZaEmlSK4JuF1Fn4+lb/i7wXrV9rFreLpF nqiR26Ru4nMMrMBgkt35zXXTeNNOjkeKOKeZ0dlIVeoX7zD2FLJ4005WXZFcSo0aymRIyQqt0J9K AeHrWvynEeFfA3iKy8YxanJajS9ORCJLcXhmEmQR/UflWrpEfiXwk13ZwaN9sgkmMiOHA4JroofG enSzRp5c6pKzLHMU+R9oySD+FNj8b6Y0buY51RYmlQlf9Yo6kUHTRjWpqUXTunuY2i+HNVu11y91 K3W2m1KLYke7JWotNufE+i6GNG/4R8zbFZBKsgwQc8/rXQp4y0/yZ3mjuIWhRZBG6fM6t0wKV/GF nHb7pba5imMvlrA8eGY4zxmg3davJtSp3u1p8tLa9iPwPo1zoehGG+2rNLIZCoP3c9qK1dK1W21m 0+0Wu4hWKOrDBVh1BooPNrSnOo5T0bPmWyvJNP1KC8i+/BKJBj2PSvU/+F4wEcaFMTj/AJ6jrXlA UGXGOOtTW6KzYIyKR7Tw0az94h1Ce41LULm9lX57iRpG/E9K7/wj8UH8PeH4NKudNkumgJCSLIB8 ueB+FcWQBkUwDjNBs8DTaSZ0njXxOfGl9bT/AGdraK3QqELbsknOa2PC/gZvE+hWE0N8tt/Z980u Cmd/3Tj26VxkYww+lexfCb/kWZ/+vg/yFNE4/D06OF91dSXS/h/Jp3xAvPFDX6SLc7v3GzkZx3/C u02DsB+VHrSj7pPeg+cOE0T4b/2bJrv2jUfOj1Y5ARMGM7sg+5rRbwjdXhVNS1iW4ijjMcaIgXqM ZPr0rqe496XqKDWFecFZM5M+C5biOQXmpNLJ5KwRsIwAiggj8eKs33hJL2W8kN0yPcxRopA5Qp0I roxzQKC/rVXucm3ghUgtPIvAJoI2jZ5Yg4k3HJbB75rR07w8unX0l155m32ywFSoHTPPHrmtvotN kOEOKBSxVWSs2eeWmi30t/aWJguo7O3nkJWRAFjUg9GHXrWvH4IItZbVr1fK8po49sKqwB7k9663 Az0oA5+lM1njaj20ObvfCEd7I8hu3Qm3jhQqv3SpyDTLrwlc3sayXmpma6SUSIzRjYvGMba6juKM dBQZLE1O5n6Nph0qxMDzeczOXLBAoyewA7UVoUUjGUuZ3e5//9k= ------=_NextPart_000_0142_01C642B6.310B19D0-- --===============1545320746== 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 --===============1545320746==-- From sip-bounces@ietf.org Wed Mar 08 09:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzT9-0005gX-7b; Wed, 08 Mar 2006 09:16:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzT7-0005dn-AM for sip@ietf.org; Wed, 08 Mar 2006 09:16:49 -0500 Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGzT5-0002tG-Tp for sip@ietf.org; Wed, 08 Mar 2006 09:16:49 -0500 From: Shimshon.Lapushner@ecitele.com To: sip@ietf.org Message-ID: Date: Wed, 8 Mar 2006 16:16:41 +0200 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 | December 22, 2004) at 03/08/2006 16:24:11 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Sip] Shimshon Lapushner/ECI Telecom is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 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 08/03/2006 and will not return until 20/03/2006. I could be reached by Mobile: +972 54 578-8113 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 10:23:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0U9-0002yI-3B; Wed, 08 Mar 2006 10:21:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0U8-0002uh-5d for sip@ietf.org; Wed, 08 Mar 2006 10:21:56 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH0U4-0005F7-O5 for sip@ietf.org; Wed, 08 Mar 2006 10:21:56 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k28FKCSV031647 for ; Wed, 8 Mar 2006 17:20:15 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 17:21:51 +0200 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 17:21: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: Wed, 8 Mar 2006 17:21:50 +0200 Message-ID: <719D5CCC2F6E3644B0A9F5C9B1D0008801839818@esebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: discovering sip-outbound keep-alive support Thread-Index: AcZCxAWjmnyVLRZyQuSJ7b2mP7TjMg== From: To: X-OriginalArrivalTime: 08 Mar 2006 15:21:51.0934 (UTC) FILETIME=[06A815E0:01C642C4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] discovering sip-outbound keep-alive support X-BeenThere: sip@ietf.org X-Mailman-Version: 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 all, has the ability for UAs to automatically discover whether support is=20 available for sip-outbound keep-alives been considered? So adding something like the OPTIONS-based mechanism in section 4.1 of=20 RFC3486 (SIP sigcomp), or relaying this information in the response=20 to REGISTER (Path and Supported headers already provide some hints)? At=20 least the -02 draft does not discuss this issue. --=20 first.surname@nokia.com (Kai Vehmanen) Under work: Sofia-SIP at http://sofia-sip.sf.net _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 11:37:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1cx-0005hz-Hh; Wed, 08 Mar 2006 11:35:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1cv-0005hu-QX for sip@ietf.org; Wed, 08 Mar 2006 11:35:05 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH1cv-0007ez-Em for sip@ietf.org; Wed, 08 Mar 2006 11:35:05 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by test-iport-1.cisco.com with ESMTP; 08 Mar 2006 08:35:04 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k28GZ121018653; Wed, 8 Mar 2006 08:35:04 -0800 (PST) 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.211); Wed, 8 Mar 2006 11:35:04 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 11:35:04 -0500 Message-ID: <440F07B7.3020104@cisco.com> Date: Wed, 08 Mar 2006 11:35:03 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xiao Wang Subject: Re: [Sip] Re: Dialog usage: Forking impacts References: <02e401c6425f$9b95f420$b2b04c0a@china.huawei.com> In-Reply-To: <02e401c6425f$9b95f420$b2b04c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2006 16:35:04.0229 (UTC) FILETIME=[40AB1D50:01C642CE] X-Spam-Score: 2.1 (++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: sip@ietf.org, christer.holmberg@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 Xiao Wang wrote: > I think that reuse early dialog may be risk. Because SUBSCRIBE may arrive at > UA1 before 1xx or 2xx for the reason of net delay or lose, so UA1 doesn't > find out a match dialog for SUBSCRIBE, finally the SUBSCRIBE will be > dropped, and return 400. If UA2 sends an *confirmed* 1xx to establish the early dialog, and then sends the subscribe after receiving confirmation (via prack) then there is no risk. If UA2 sends an *unconfirmed* 1xx and then sends a subscribe within the dialog, there is risk that UA1 won't know about the dialog. In that case UA1 should be sending a 481 response, and UA2 will know what happened. There should be no dropping of the subscribe. Paul > Xiao > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Friday, March 03, 2006 11:26 PM >>To: Christer Holmberg (JO/LMF) >>Cc: IETF SIP List >>Subject: [Sip] Re: Dialog usage: Forking impacts >> >> >> >>Christer Holmberg (JO/LMF) wrote: >> >>>Hi, >>> >>>Another scenario related to the dialog usage issue: >>> >>>1. UA_1 sends an INVITE, which gets forked to UA_2 and UA_3. >>> >>>2. UA_2 establish an early dialog with UA_1 and sends a SUBSCRIBE >>>(or any other request establishing a new dialog usage) to UA_1, >>>establishing a dialog usage (subscribe dialog usage in case of > > SUBSCRIBE). > >>>3. UA_3 acceptes the session for the INVITE and sends 200 OK > > (INVITE) > >>>4. The forking proxy sends a CANCEL to UA_2, and forwards the 200 >>>OK (INVITE) to UA_1. >>> >>>5. UA_1, when receiving the 200 OK, would normally terminate the >>>early dialog between itself and UA_2. BUT, in this case it can't do it, >>>because it still has an active subscription dialog usage association >>>with UA_2, and the CANCEL sent by the proxy didn't terminate that dialog >>>usage in UA_2 either. >> >>This does point up some issues with language in the RFCs. I doubt there >>really is any such thing as an "early dialog". In reality there is only >>one kind of dialog, but there is an "early invite dialog usage". >> >> >>>Now, the dialog usages still share the same dialog, but from the UA_1 >>>perspective each dialog usage has DIFFERENT route sets and remote > > targets... > >>Don't think I agree. Following step 3, or maybe sooner, UA1 knows there >>are two dialogs, because it has received responses with different >>to-tags. The early invite dialog usage with UA2 and the subscribe from >>UA2 share one dialog, and the invite dialog usage with UA3 uses the >>other dialog. >> >>There isn't anything new here due to sharing. UA2 and UA3 could have >>both established early invite dialog usages. UA1 has to deal with two >>dialogs in that case as well. >> >>The key thing in all this is that the lifetime of dialogs is not >>explicitly managed. Rather it is reference counted based on the usages >>that share it. >> >> >>>Saying that dialog re-usage is only allowed for FULLY ESTABLISHED >>>dialogs would of course solve this, but currentely I think it's legal >>>from a pure SIP perspective. Or? >> >>This is one of the reasons why I think it is a bad idea to start putting >>restrictions on the use of shared dialogs. As things stand, the whole >>ediface does tie together using just a few basic principles. If you >>support those principles, then all the different possible combinations >>of usages will work. If you impose restrictions on the kinds of usages >>that are allowed, you encourage implementations that implement all sorts >>of special case logic. Figuring out what special case logic is >>sufficient is harder than implementing the general case. >> >> Paul >> >> >>>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 From sip-bounces@ietf.org Wed Mar 08 11:56:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1w5-0005JF-Cn; Wed, 08 Mar 2006 11:54:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1w3-0005J2-Lg for sip@ietf.org; Wed, 08 Mar 2006 11:54:51 -0500 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 1FH1w2-0008On-AR for sip@ietf.org; Wed, 08 Mar 2006 11:54:51 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2006 08:54:49 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k28GsYwP028766 for ; Wed, 8 Mar 2006 08:54:49 -0800 (PST) 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.211); Wed, 8 Mar 2006 11:54:46 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 11:54:46 -0500 Message-ID: <440F0C56.7050205@cisco.com> Date: Wed, 08 Mar 2006 11:54:46 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] The Problem with PRACK References: <440E5E52.20500@cisco.com> In-Reply-To: <440E5E52.20500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2006 16:54:46.0800 (UTC) FILETIME=[01892100:01C642D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 wrote: > At the last IETF, there was a lot of discussion and argument around > PRACK. The spark of this debate was the ICE specification, which had > words in it requiring the usage of PRACK and UPDATE in order to work > with early media. There was strong pushback from many implementors that > anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) > that showed the state machine in his implementation resulting from > PRACK, and it was not pretty. > > So, I'd like to discuss exactly what IS the problem with PRACK? There > are really two pieces of state machinery in play here. One piece is the > complication that PRACK introduces into the offer/answer model. With > PRACK, you can now get a final answer in the 18x, and then send a new > offer in UPDATE, or even in PRACK itself. Another piece is the state > machinery with the retransmissions itself - correlating the PRACK with a > particular reliable provisional response and causing it to stop. > > In a chat with Flemming today, he suggested in interested remedy to our > PRACK dilemma. Why not revise PRACK so that you can't send an offer or > answer with it; it has no impact on the set of allowed O/A exchanges > defined by RFC 3261. I'm not sure if that would consequently break the > preconditions mechanism, but maybe there are some kind of offer/answer > limitations that would simplify things. The precondition *mechanism* could still work, using UPDATE, though somewhat less efficiently. But it would have to be modified so that it no longer specifies using PRACK. Unless you believe *nobody* currently uses preconditions, it seems to be that this cat is already out of the bag, and putting it back in will be difficult. > So, this is one idea. I'd like for people who have complained about > PRACK implementations to speak up and indicate what exactly makes it so > complicated for them. The advantage here is that it simplifies life for those who want to use PRACK for reasons unrelated to offer/answer. It leaves UPDATE, along with INVITE, to handle offer/answer. But, I also see people wanting to use UPDATE as a way to do things like session-timer updates without the risk of starting a new offer/answer cycle. UPDATE does allow this, but if you advertise support for UPDATE you cannot guarantee it won't be used to send you an offer. I think the real problem is that people are too damn lazy to implement the more elaborate offer/answer model, and they are trying to find a way to avoid doing so. IMO adding restrictions on the mechanisms that are involved in this is a big hammer approach. To me it is now clear what must be done to implement this, and doing so is easier than coping with changes at this late date. 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 Wed Mar 08 12:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2p3-0002Ci-BJ; Wed, 08 Mar 2006 12:51:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2p2-0002Ca-0d for sip@ietf.org; Wed, 08 Mar 2006 12:51:40 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH2p0-00026x-Jg for sip@ietf.org; Wed, 08 Mar 2006 12:51:39 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k28HpTGI016981; Wed, 8 Mar 2006 18:51:29 +0100 Received: from [172.25.79.32] ([172.25.79.32]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006030818512774:3257 ; Wed, 8 Mar 2006 18:51:27 +0100 Message-ID: <440F199F.2060007@alcatel.fr> Date: Wed, 08 Mar 2006 18:51:27 +0100 From: Thomas.Levy@alcatel.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.7) Gecko/20050414 X-Accept-Language: fr, en MIME-Version: 1.0 To: fluffy@cisco.com, rohan@ekabal.com X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/08/2006 18:51:27, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/08/2006 18:51:29, Serialize complete at 03/08/2006 18:51:29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org Subject: [Sip] Outbound and GRUU, X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen and Rohan, Could you provide explanations on relation between Outbound and GRUU. In fact, I didn't follow whole the threads concerning the Outbound draft, perhaps it may explain my question. However, could you answer the following points: In my understanding, GRUU is useful when an AOR may be registered simultaneously on multiple UA instances. However, the scope (and requirements) from Outbound seem different. So, what are the motivations for making outbound fully dependent from GRUU? For instance, in my opinion, a user registered on a natted UA could use outbound (and thus have a persistent connection with its proxy) without having an instance ID. Why is it mandatory for a UA to have an Instance ID (as explained in section 4.1) for outbound? Thanks for your help. Thomas LEVY _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 14:52:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH4gY-0004NM-CB; Wed, 08 Mar 2006 14:51:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH4gW-0004Hf-P2 for sip@ietf.org; Wed, 08 Mar 2006 14:51:00 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH4gV-00060w-Ig for sip@ietf.org; Wed, 08 Mar 2006 14:51:00 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 1DDAF6C017 for ; Wed, 8 Mar 2006 14:50:59 -0500 (EST) Subject: Re: [Sip] Outbound and GRUU, From: "Dale R. Worley" To: Sip In-Reply-To: <440F199F.2060007@alcatel.fr> References: <440F199F.2060007@alcatel.fr> Content-Type: text/plain Date: Wed, 08 Mar 2006 14:50:58 -0500 Message-Id: <1141847458.3832.20.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Wed, 2006-03-08 at 18:51 +0100, Thomas.Levy@alcatel.fr wrote: > In my understanding, GRUU is useful when an AOR may be registered > simultaneously on multiple UA instances. GRUU can be useful even when an AOR is registered to only one UA. GRUU is needed any time that the actual contact URI of the UA is not globally routable. When contact URIs are not globally routable, without GRUU, native SIP-based call control can't be made to work. So in any situation where you are discussing outbound/STUN/ICE/etc., you can assume that UAs are using GRUU. 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 Mar 08 15:35:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5LQ-0000io-4m; Wed, 08 Mar 2006 15:33:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5LP-0000ij-54 for sip@ietf.org; Wed, 08 Mar 2006 15:33:15 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5LM-0007pG-LS for sip@ietf.org; Wed, 08 Mar 2006 15:33:15 -0500 Received: (qmail 14401 invoked by uid 0); 8 Mar 2006 20:33:08 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Mar 2006 20:33:08 -0000 Message-ID: <03da01c642ef$83391110$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: References: Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-05.txt Date: Wed, 8 Mar 2006 21:33:09 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: sip@ietf.org X-Mailman-Version: 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 suggestion: Instead of installing the alias at the time a request with a top Via containing 'alias' is received, what about doing it the moment a 101-2xx response is forwarded back upstream? I think this would avoid some of the attacks described in section 9.3. The reason to include 1xx responses, is that e.g. an UPDATE sent during early dialog would be able to use the aliased connection. Also, for security reasons perhaps the types of requests that may carry an alias should be restricted. For example, a CANCEL may not be challenged, so it would not be wise to allow it to establish an alias. Same for ACK, and what about OPTIONS? Regards, Jeroen >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 : Connection Reuse in the Session Initiation Protocol (SIP) > Author(s) : R. Mahy, et al. > Filename : draft-ietf-sip-connect-reuse-05.txt > Pages : 16 > Date : 2006-3-7 > > When SIP entities use a connection oriented protocol to send a > request, they typically originate their connections from an ephemeral > port. The SIP protocol includes mechanisms which insure that > responses to a request, and new requests sent in the original > direction reuse an existing connection. However, new requests sent > in the opposite direction are unlikely to reuse the existing > connection. This frequently causes a pair of SIP entities to use one > connection for requests sent in each direction, and can result in > potential scaling and performance problems. This document proposes > requirements and a mechanism which address this deficiency in > environments where the connection could be opened in either > direction. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-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-connect-reuse-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-connect-reuse-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. > -------------------------------------------------------------------------------- > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 16:34:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6Gp-0001JX-KU; Wed, 08 Mar 2006 16:32:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6Go-0001JS-ED for sip@ietf.org; Wed, 08 Mar 2006 16:32:34 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH6Gn-00083U-4G for sip@ietf.org; Wed, 08 Mar 2006 16:32:34 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IVT00B01VPMB4@siemenscomms.co.uk> for sip@ietf.org; Wed, 08 Mar 2006 21:29:47 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IVT00A35VPMFV@siemenscomms.co.uk>; Wed, 08 Mar 2006 21:29:46 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 08 Mar 2006 21:32:31 +0000 Content-return: allowed Date: Wed, 08 Mar 2006 21:32:30 +0000 From: "Elwell, John" Subject: RE: AW: [Sip] Updated connected-identity draft To: Christer Holmberg , "Alexeitsev, D" Message-id: <50B1CBA96870A34799A506B2313F26670851FBE2@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, ilan.avner@audiocodes.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 Christer, The agreement in Vancouver concerned changing the URI in the From header mid-dialog. In my opinion changing the URI in the To header mid-dialog (or even in a dialog-forming response) is a similar issue and might also be acceptable to the community. John > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 08 March 2006 12:13 > To: Alexeitsev, D; Elwell, John > Cc: sip@ietf.org; ilan.avner@audiocodes.com > Subject: Re: AW: [Sip] Updated connected-identity draft > > Hi, > > Currently, you are not allowed to change the value of the To > header in an UPDATE either. > > >From a pure SIP protocol perspective only the tag is used > for dialog identification, so changing the "phone number" > part should have no core impacts - but some implementations > may of course always check the whole header. > > And, if one were allowed to change the phone number part (not > only from 180 to 200, but also in other cases), would some of > the existing extension/P- headers be made obselete? > > 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 Wed Mar 08 16:38:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6LJ-0003PX-4t; Wed, 08 Mar 2006 16:37:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6LH-0003OH-EI for sip@ietf.org; Wed, 08 Mar 2006 16:37:11 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH6LG-0008LG-0D for sip@ietf.org; Wed, 08 Mar 2006 16:37:11 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4F5675AE; Wed, 8 Mar 2006 22:37:09 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 22:37:09 +0100 Received: from [136.225.183.90] ([136.225.183.90]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 22:37:05 +0100 From: "Christer Holmberg" To: "Paul Kyzivat" , "Jonathan Rosenberg" Subject: Re: [Sip] The Problem with PRACK Date: Wed, 8 Mar 2006 23:32:15 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Mar 2006 21:37:08.0719 (UTC) FILETIME=[73B4CFF0:01C642F8] X-Brightmail-Tracker: AAAAAA== 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 Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, When you ask whether people have implemented preconditions, you also need = to ask if they have implemented it using PRACK for sending SDP offer. As = you said, it COULD be done with UPDATE instead, and I don't think the = precondition mechanism forbids it. Anothet question, though: if you send an empty INVITE, and receive an offer = in a reliable 18x, how would you send the answer? Using UPDATE? 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 Mar 08 16:57:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6cp-0002wv-UG; Wed, 08 Mar 2006 16:55:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6co-0002wg-LO for sip@ietf.org; Wed, 08 Mar 2006 16:55:18 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH6cn-000270-7O for sip@ietf.org; Wed, 08 Mar 2006 16:55:18 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 62F40750; Wed, 8 Mar 2006 22:55:16 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 22:55:16 +0100 Received: from [136.225.183.68] ([136.225.183.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 22:55:12 +0100 From: "Christer Holmberg" To: "Elwell, John" , "Alexeitsev, D" Subject: RE: AW: [Sip] Updated connected-identity draft Date: Wed, 8 Mar 2006 23:50:21 +0200 Message-ID: <6hMGXbMptJb9.xVqqb1Jc@se-smtp.ericsson.se> X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Mar 2006 21:55:15.0718 (UTC) FILETIME=[FB9BB260:01C642FA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org, ilan.avner@audiocodes.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, So, to clarify: this would mean that any node, at any time, is allowed to = change the URI in the To- and From headers? Or, are we defining some special situations when it's allowed? Regards, Christet _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 17:20:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6z8-0005qf-67; Wed, 08 Mar 2006 17:18:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6z7-0005qa-GH for sip@ietf.org; Wed, 08 Mar 2006 17:18:21 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH6z6-0004HS-79 for sip@ietf.org; Wed, 08 Mar 2006 17:18:21 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IVT00M01XTYR7@siemenscomms.co.uk> for sip@ietf.org; Wed, 08 Mar 2006 22:15:34 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IVT00I7UXTYQK@siemenscomms.co.uk>; Wed, 08 Mar 2006 22:15:34 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 08 Mar 2006 22:18:19 +0000 Content-return: allowed Date: Wed, 08 Mar 2006 22:18:17 +0000 From: "Elwell, John" Subject: RE: AW: [Sip] Updated connected-identity draft To: Christer Holmberg , "Alexeitsev, D" Message-id: <50B1CBA96870A34799A506B2313F26670851FBEE@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip@ietf.org, ilan.avner@audiocodes.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 Christer, This was agreed for further exploration as the solution to the connected-identity problem, rather than the other solutions on the table at the time. However, the discussion really only concerned the From header URI, not the To header URI. Hence the open issue in the current connected-identity draft concerning the To header URI. John > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 08 March 2006 21:50 > To: Elwell, John; Alexeitsev, D > Cc: sip@ietf.org; ilan.avner@audiocodes.com > Subject: RE: AW: [Sip] Updated connected-identity draft > > Hi, > > So, to clarify: this would mean that any node, at any time, > is allowed to change the URI in the To- and From headers? > > Or, are we defining some special situations when it's allowed? > > Regards, > > Christet > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 18:01:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH7cy-0001fs-FG; Wed, 08 Mar 2006 17:59:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH7cw-0001fC-R2 for sip@ietf.org; Wed, 08 Mar 2006 17:59:30 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH7cu-0006El-4L for sip@ietf.org; Wed, 08 Mar 2006 17:59:30 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k28MxJOS056006; Wed, 8 Mar 2006 17:59:24 -0500 (EST) From: "Brett Tate" To: "'Jonathan Rosenberg'" , "'IETF SIP List'" Subject: RE: [Sip] The Problem with PRACK Date: Wed, 8 Mar 2006 18:00:22 -0500 Message-ID: <002701c64304$14c590e0$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <440E5E52.20500@cisco.com> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 > So, I'd like to discuss exactly what IS the problem > with PRACK? There are really two pieces of state > machinery in play here. One piece is the=20 > complication that PRACK introduces into the=20 > offer/answer model. With PRACK, you can now get a=20 > final answer in the 18x, and then send a new=20 > offer in UPDATE, or even in PRACK itself.=20 An offer within the prack is a pain and potentially a little under specified. One problem is that some devices don't support receiving prack with an offer. Thus the sender needs to handle PRACK 200 without SDP and handle = a failure response because of the sdp. And if the UAS does not accept the offer, some vendors return 488/606 type responses; others return 200 = without SDP. I prefer removing ability for prack to contain an offer. However = leaving it is ok if vendors who send it can deal with the typical interop problems. > Another piece is the state machinery with the=20 > retransmissions itself - correlating the PRACK=20 > with a particular reliable provisional response=20 > and causing it to stop. I'm not aware of this being very complicated. > Why not revise PRACK so that you can't send an=20 > offer or answer with it; it has no impact on the=20 > set of allowed O/A exchanges defined by RFC 3261.=20 > I'm not sure if that would consequently break the=20 > preconditions mechanism, but maybe there are some=20 > kind of offer/answer limitations that would simplify=20 > things. Answer within prack is needed unless willing to allow subsequent = different offer from the uas (UPDATE; and maybe other 18x and 2xx) to still = override first 18x offer. > So, this is one idea. I'd like for people who have=20 > complained about PRACK implementations to speak up=20 > and indicate what exactly makes it so complicated=20 > for them. It isn't complicated. It is just a matter of getting it implemented and deployed; and dealing with the various interoperability pains. (BTW draft-sawada-sipping-sip-offeranswer has been a good reference for = answering many of the common questions about offer/answer within sip; hopefully = the draft gets adopted by sipping or sip.) One reason devices don't (or quit) supporting 100rel was because of the SHOULDs/MUSTs related to offer/answer. Another reason is because of the extra messaging. And because subsequent SDPs sent within INVITE 18x/2xx no longer have precedent over the prior SDP, interoperability is a pain. The UAS now requires rfc3311 and rfc3262 support, and/or ability for UAC to finally support forking interactions (18x/2xx with different tags). The following are a few random things currently not resolved and/or = clearly specified. Others are just some random thoughts/rants concerning interoperability. 1) Dealing with 18x offer/answer rules with timer c is under specified. Should the periodic 18x contain an SDP again? And if so, which one if another sent in UPDATE, PRACK, or their responses? 2) RFC3261 discusses possibility of sending SDP again in INVITE 200 response. And it says it must be same as prior 18x SDP. However I = assume if some send it (for backwards compatibility reasons), UAS should send = the latest correct SDP (if different SDP sent in UPDATE, PRACK response, or UPDATE response). 3) A forking proxy currently has no mechanism to indicate to uac when a branch has been terminated. Thus the UAC is currently unable to easily determine which early dialogs have disappeared. Hopefully this functionality will get resolved/included within herfp or another draft. 4) Concerning UPDATE and SDP, some vendors think SDP is required. And = some vendors can't handle receiving the 504 response mentioned within rfc3311 without releasing the call. 5) "audit" with sdp is pain (especially when prior "answer" becomes = "offer" within audit). This is mainly just a pain to B2BUAs. Hopefully more devices will start correctly support receiving UPDATE without SDP. 6) Some devices still do not support forking proxy interactions very = well because some B2BUAs reduced the need. And because of all the current offer/answer rules, devices expecting correct offer/answer behavior need = to interact well with forking proxies. I mention this because if a UAS = needs to update the SDP and can't (because of offer/answer rules, etcetera), = it might act like forking occurred and send a 18x/2xx with a different tag. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 18:13:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH7oJ-0004Mg-0a; Wed, 08 Mar 2006 18:11:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH7oI-0004MU-1d for sip@ietf.org; Wed, 08 Mar 2006 18:11:14 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH7oG-0007JC-KT for sip@ietf.org; Wed, 08 Mar 2006 18:11:13 -0500 Received: (from apache@localhost) by figas.ekabal.com (8.11.6/8.11.6) id k28NB4b18711; Wed, 8 Mar 2006 15:11:04 -0800 From: Rohan Mahy X-Authentication-Warning: figas.ekabal.com: apache set sender to rohan@localhost using -f Received: from 12.151.41.2 (SquirrelMail authenticated user rohan); by figas.ekabal.com with HTTP; Wed, 8 Mar 2006 15:11:04 -0800 (PST) Message-ID: <14203.12.151.41.2.1141859464.squirrel@12.151.41.2> In-Reply-To: <440F199F.2060007@alcatel.fr> References: <440F199F.2060007@alcatel.fr> Date: Wed, 8 Mar 2006 15:11:04 -0800 (PST) To: Thomas.Levy@alcatel.fr User-Agent: SquirrelMail/1.4.3a-1 X-Mailer: SquirrelMail/1.4.3a-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org Subject: [Sip] Re: Outbound and GRUU, X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Thomas, The instance ID is required so that the proxy can tell it is dealing with the same UA instance. It doesn't matter if in a real deployment you might only have one instance. Remember that with outbound you are encouraged to use multiple flows, all with the same instance id. Outbound solves a general problem. Even if an instance id might not be needed in a specific use case, it does not hurt anything to include it. hope this helps. thanks, -rohan > Cullen and Rohan, > > Could you provide explanations on relation between Outbound and GRUU. > In fact, I didn't follow whole the threads concerning the Outbound > draft, perhaps it may explain my question. > However, could you answer the following points: > In my understanding, GRUU is useful when an AOR may be registered > simultaneously on multiple UA instances. > However, the scope (and requirements) from Outbound seem different. > So, what are the motivations for making outbound fully dependent from > GRUU? > For instance, in my opinion, a user registered on a natted UA could use > outbound (and thus have a persistent connection with its proxy) without > having an instance ID. > Why is it mandatory for a UA to have an Instance ID (as explained in > section 4.1) for outbound? > > Thanks for your help. > > Thomas LEVY > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 18:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH8Av-0002Xa-Fr; Wed, 08 Mar 2006 18:34:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH8Au-0002Ti-1k for sip@ietf.org; Wed, 08 Mar 2006 18:34:36 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH8As-00086e-Ox for sip@ietf.org; Wed, 08 Mar 2006 18:34:36 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2006 15:34:34 -0800 X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208"; a="1783259886:sNHT30772452" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k28NYXw1025706; Wed, 8 Mar 2006 15:34:34 -0800 (PST) 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.211); Wed, 8 Mar 2006 18:34:33 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 18:34:33 -0500 Message-ID: <440F6A08.5090206@cisco.com> Date: Wed, 08 Mar 2006 18:34:32 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] The Problem with PRACK References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2006 23:34:33.0025 (UTC) FILETIME=[DA709B10:01C64308] 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 Christer Holmberg wrote: > Hi, > > When you ask whether people have implemented preconditions, you also need to ask if they have implemented it using PRACK for sending SDP offer. As you said, it COULD be done with UPDATE instead, and I don't think the precondition mechanism forbids it. I think that is fine. But it has examples showing use of PRACK > Anothet question, though: if you send an empty INVITE, and receive an offer in a reliable 18x, how would you send the answer? Using UPDATE? In PRACK. The current understanding is that you may not send an answer in UPDATE. But that does show that we couldn't just ban PRACK for offer/answer. If you wanted to do that then we would have to allow an answer in an UPDATE. > 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 Mar 08 18:44:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH8Ii-0006Oz-9H; Wed, 08 Mar 2006 18:42:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH8Ih-0006Or-1l for sip@ietf.org; Wed, 08 Mar 2006 18:42:39 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH8Ig-0008SW-Ho for sip@ietf.org; Wed, 08 Mar 2006 18:42:39 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Mar 2006 15:42:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208"; a="23243511:sNHT25776766" 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 k28NgbWc013504; Wed, 8 Mar 2006 18:42:38 -0500 (EST) 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.211); Wed, 8 Mar 2006 18:42:37 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 18:42:37 -0500 Message-ID: <440F6BEC.2000604@cisco.com> Date: Wed, 08 Mar 2006 18:42:36 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Tate Subject: Re: [Sip] The Problem with PRACK References: <002701c64304$14c590e0$2c28a8c0@brett1> In-Reply-To: <002701c64304$14c590e0$2c28a8c0@brett1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2006 23:42:37.0610 (UTC) FILETIME=[FB4668A0:01C64309] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 Brett Tate wrote: >>So, I'd like to discuss exactly what IS the problem >>with PRACK? There are really two pieces of state >>machinery in play here. One piece is the >>complication that PRACK introduces into the >>offer/answer model. With PRACK, you can now get a >>final answer in the 18x, and then send a new >>offer in UPDATE, or even in PRACK itself. > > > An offer within the prack is a pain and potentially a little under > specified. > > One problem is that some devices don't support receiving prack with an > offer. There are lots of things that some devices don't support. We call those cases BUGS. Which devices are those? > Thus the sender needs to handle PRACK 200 without SDP and handle a > failure response because of the sdp. Are you suggesting that it is *legal* to: - support PRACK - not support PRACK with sdp? I don't think that is valid. Prack use is enabled via the 100rel option. I'm pretty sure that option comes with the whole boat. > And if the UAS does not accept the > offer, some vendors return 488/606 type responses; others return 200 without > SDP. > > I prefer removing ability for prack to contain an offer. However leaving it > is ok if vendors who send it can deal with the typical interop problems. You only want to remove ability for it to contain an offer, but allow it to contain an answer? Or remove support for both offer and answer? As I noted in earlier reply, if we were to do that, then how do you answer an offer that comes in a reliable provisional response? Any change in this stuff has backward compatibility issues. It would require use of new option tags, and even more complex support than the existing situation does. Paul >>Another piece is the state machinery with the >>retransmissions itself - correlating the PRACK >>with a particular reliable provisional response >>and causing it to stop. > > > I'm not aware of this being very complicated. > > > >>Why not revise PRACK so that you can't send an >>offer or answer with it; it has no impact on the >>set of allowed O/A exchanges defined by RFC 3261. >>I'm not sure if that would consequently break the >>preconditions mechanism, but maybe there are some >>kind of offer/answer limitations that would simplify >>things. > > > Answer within prack is needed unless willing to allow subsequent different > offer from the uas (UPDATE; and maybe other 18x and 2xx) to still override > first 18x offer. > > > >>So, this is one idea. I'd like for people who have >>complained about PRACK implementations to speak up >>and indicate what exactly makes it so complicated >>for them. > > > It isn't complicated. It is just a matter of getting it implemented and > deployed; and dealing with the various interoperability pains. (BTW > draft-sawada-sipping-sip-offeranswer has been a good reference for answering > many of the common questions about offer/answer within sip; hopefully the > draft gets adopted by sipping or sip.) > > One reason devices don't (or quit) supporting 100rel was because of the > SHOULDs/MUSTs related to offer/answer. Another reason is because of the > extra messaging. > > And because subsequent SDPs sent within INVITE 18x/2xx no longer have > precedent over the prior SDP, interoperability is a pain. The UAS now > requires rfc3311 and rfc3262 support, and/or ability for UAC to finally > support forking interactions (18x/2xx with different tags). > > > The following are a few random things currently not resolved and/or clearly > specified. Others are just some random thoughts/rants concerning > interoperability. > > 1) Dealing with 18x offer/answer rules with timer c is under specified. > Should the periodic 18x contain an SDP again? And if so, which one if > another sent in UPDATE, PRACK, or their responses? > > 2) RFC3261 discusses possibility of sending SDP again in INVITE 200 > response. And it says it must be same as prior 18x SDP. However I assume > if some send it (for backwards compatibility reasons), UAS should send the > latest correct SDP (if different SDP sent in UPDATE, PRACK response, or > UPDATE response). > > 3) A forking proxy currently has no mechanism to indicate to uac when a > branch has been terminated. Thus the UAC is currently unable to easily > determine which early dialogs have disappeared. Hopefully this > functionality will get resolved/included within herfp or another draft. > > 4) Concerning UPDATE and SDP, some vendors think SDP is required. And some > vendors can't handle receiving the 504 response mentioned within rfc3311 > without releasing the call. > > 5) "audit" with sdp is pain (especially when prior "answer" becomes "offer" > within audit). This is mainly just a pain to B2BUAs. Hopefully more > devices will start correctly support receiving UPDATE without SDP. > > 6) Some devices still do not support forking proxy interactions very well > because some B2BUAs reduced the need. And because of all the current > offer/answer rules, devices expecting correct offer/answer behavior need to > interact well with forking proxies. I mention this because if a UAS needs > to update the SDP and can't (because of offer/answer rules, etcetera), it > might act like forking occurred and send a 18x/2xx with a different tag. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 19:51:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH9L5-0007oL-0i; Wed, 08 Mar 2006 19:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH9L3-0007nt-RF for sip@ietf.org; Wed, 08 Mar 2006 19:49:09 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH8ff-00020f-Jm for sip@ietf.org; Wed, 08 Mar 2006 19:06:23 -0500 Received: from pproxy.gmail.com ([64.233.166.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FH8RC-0008TK-6W for sip@ietf.org; Wed, 08 Mar 2006 18:51:28 -0500 Received: by pproxy.gmail.com with SMTP id z74so27914pyg for ; Wed, 08 Mar 2006 15:51:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=haikdWIVWJ1pLwfxtwChngPmElPfZD8+mqeDztnFoBFXLjbRV+T5k0sBbrM4zSPMToLjiVjrW9OuMmmLFaRnOduo5XiVFVuTKoQrFKssKpjTZdrSQOaSwi+dTRGLf6MwInmC6/TbiLqGpu/AcJPxGSVG7nrWiAr+eS1nZiOLOEQ= Received: by 10.35.105.18 with SMTP id h18mr305967pym; Wed, 08 Mar 2006 15:51:24 -0800 (PST) Received: by 10.35.58.20 with HTTP; Wed, 8 Mar 2006 15:51:24 -0800 (PST) Message-ID: <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> Date: Wed, 8 Mar 2006 15:51:24 -0800 From: "Rohan Mahy" To: "Jonathan Rosenberg" Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <440E5E52.20500@cisco.com> MIME-Version: 1.0 References: <440E5E52.20500@cisco.com> X-Spam-Score: -2.3 (--) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f 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="===============0261098538==" Errors-To: sip-bounces@ietf.org --===============0261098538== Content-Type: multipart/alternative; boundary="----=_Part_13392_8321567.1141861884414" ------=_Part_13392_8321567.1141861884414 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, A things about PRACK come immediately to mind that are a pain to implement: 1) The UAS has to queue provisionals until it receives a PRACK for the firs= t provisional. This is due to RSeq starting at an arbitrary value instead of just starting at 1. This is probably the simplest to fix, by just requirin= g the UAC to always start with a RSeq of 1. 2) Multiple unacknowledged provisionals can be in flight at the same time. We could potentially eliminate this requirement by acknowledging the curren= t status instead of the whole history. In other words, when the UAS sends a new reliable provisional, it decides which (if any) of the previously sent provisionals are still relevant and sends all of them (as sipfrags or something) as a single reliable request. 3) If you "answer" and want to deliver a 200 OK, you have to queue it and wait if you are waiting for a PRACK to an offer or answer. Keeping track of when you can send the 200 would be easier if we did something like I recommend in #2. 4) Even for an acknowledged provisional, you still have to retransmit approximately every minute (I forget exactly) to prevent old proxies from deleting state for your transaction. This is one of those minor annoyances that is *almost* operationally irrelevant, and unlikely to not get coded. My proposal for simplification is to retransmit the latest reliable provisional in exactly the same way that the UAS retransmits unreliable provisionals. Who cares if there is an extra message or two for a call wit= h 1 minute + post-answer delay? 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I talked Jonathan into this, and I've been sorry I did ever since. My apologies to everyone for making a bad decision. Hope this helps. thanks, -rohan On 3/7/06, Jonathan Rosenberg wrote: > > At the last IETF, there was a lot of discussion and argument around > PRACK. The spark of this debate was the ICE specification, which had > words in it requiring the usage of PRACK and UPDATE in order to work > with early media. There was strong pushback from many implementors that > anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) > that showed the state machine in his implementation resulting from > PRACK, and it was not pretty. > > So, I'd like to discuss exactly what IS the problem with PRACK? There > are really two pieces of state machinery in play here. One piece is the > complication that PRACK introduces into the offer/answer model. With > PRACK, you can now get a final answer in the 18x, and then send a new > offer in UPDATE, or even in PRACK itself. Another piece is the state > machinery with the retransmissions itself - correlating the PRACK with a > particular reliable provisional response and causing it to stop. > > In a chat with Flemming today, he suggested in interested remedy to our > PRACK dilemma. Why not revise PRACK so that you can't send an offer or > answer with it; it has no impact on the set of allowed O/A exchanges > defined by RFC 3261. I'm not sure if that would consequently break the > preconditions mechanism, but maybe there are some kind of offer/answer > limitations that would simplify things. > > So, this is one idea. I'd like for people who have complained about > PRACK implementations to speak up and indicate what exactly makes it so > complicated for them. > > 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 > ------=_Part_13392_8321567.1141861884414 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

A things about PRACK come immediately to mind that are a pain to= implement:

1) The UAS has to queue provisionals until it receives a= PRACK for the first provisional.  This is due to RSeq starting at an = arbitrary value instead of just starting at 1.  This is probably the s= implest to fix, by just requiring the UAC to always start with a RSeq of 1.

2) Multiple unacknowledged provisionals can be in flight at the sam= e time.  We could potentially eliminate this requirement by acknowledg= ing the current status instead of the whole history.  In other words, = when the UAS sends a new reliable provisional, it decides which (if any) of= the previously sent provisionals are still relevant and sends all of them = (as sipfrags or something) as a single reliable request.

3) If you "answer" and want to deliver a 200 OK, you have= to queue it and wait if you are waiting for a PRACK to an offer or answer.= Keeping track of when you can send the 200 would be easier if we did somet= hing like I recommend in #2. =20

4) Even for an acknowledged provisional, you still have to retransm= it approximately every minute (I forget exactly) to prevent old proxies fro= m deleting state for your transaction.  This is one of those minor ann= oyances that is *almost* operationally irrelevant, and unlikely to not get = coded.  My proposal for simplification is to retransmit the latest rel= iable provisional in exactly the same way that the UAS retransmits unreliab= le provisionals.  Who cares if there is an extra message or two for a = call with 1 minute + post-answer delay?

5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange.&n= bsp; I talked Jonathan into this, and I've been sorry I did ever since.&nbs= p; My apologies to everyone for making a bad decision.

Hope this hel= ps.
thanks,
-rohan

On 3/7/06, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
At the last IETF, there was a lot of discussion and argument around
PRAC= K. The spark of this debate was the ICE specification, which had
words i= n it requiring the usage of PRACK and UPDATE in order to work
with early= media. There was strong pushback from many implementors that
anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC)that showed the state machine in his implementation resulting from
PRA= CK, and it was not pretty.

So, I'd like to discuss exactly what IS t= he problem with PRACK? There
are really two pieces of state machinery in play here. One piece is the=
complication that PRACK introduces into the offer/answer model. WithPRACK, you can now get a final answer in the 18x, and then send a new
offer in UPDATE, or even in PRACK itself. Another piece is the state
mac= hinery with the retransmissions itself - correlating the PRACK with a
pa= rticular reliable provisional response and causing it to stop.

In a = chat with Flemming today, he suggested in interested remedy to our
PRACK dilemma. Why not revise PRACK so that you can't send an offer or<= br>answer with it; it has no impact on the set of allowed O/A exchanges
= defined by RFC 3261. I'm not sure if that would consequently break the
preconditions mechanism, but maybe there are some kind of offer/answer
l= imitations that would simplify things.

So, this is one idea. I'd lik= e for people who have complained about
PRACK implementations to speak up= and indicate what exactly makes it so
complicated for them.

Thanks,
Jonathan R.
--
Jonathan D= . Rosenberg, Ph.D.         &nb= sp;         600 Lanidex Plaza
Ci= sco Fellow           = ;            &n= bsp;           Parsippany= , NJ 07054-2711
Cisco Systems
jdrosen@cisco.com  &= nbsp;           &nbs= p;            &= nbsp;  FAX:   (973) 952-5050
http://www.jdrosen.net      &= nbsp;           &nbs= p;      PHONE: (973) 952-5000
http://www.cisco.com

__________= _____________________________________
Sip mailing list  https://www1.ietf.org/mail= man/listinfo/sip
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

------=_Part_13392_8321567.1141861884414-- --===============0261098538== 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 --===============0261098538==-- From sip-bounces@ietf.org Wed Mar 08 20:46:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHACZ-0000t8-EE; Wed, 08 Mar 2006 20:44:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHACX-0000mL-S4 for sip@ietf.org; Wed, 08 Mar 2006 20:44:25 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHACW-0005oQ-HJ for sip@ietf.org; Wed, 08 Mar 2006 20:44:25 -0500 Received: from [64.101.173.34] ([64.101.173.34]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k291icNN027170 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 8 Mar 2006 19:44:40 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 8 Mar 2006 19:44:19 -0600 To: "sip@ietf.org List" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Cullen Jennings , Rohan Mahy , Allison Mankin Subject: [Sip] Agenda discussion, SIP at 65 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 posted a draft agenda for SIP at: http://www.softarmor.com/sipwg/meets/ietf65/agenda.html Please note that we seem to have more to talk about than time to talk. I've populated the charter-items first with my best estimates of needed times (based on author's guesses cross-factored with what I've observed in the past). This leaves us at the most about 15 minutes for other topics. I've left several topics in an "under consideration" block for now. Are there topics that I've given too much time too or that we shouldn't talk about at all? Are there topics that need more time than I've estimated? And of the topics that are in the "under consideration" block, what should our priority be and how much time should we allocate? Thanks, -- Dean chair du-jour, SIP. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 20:47:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHAE7-0004vi-9o; Wed, 08 Mar 2006 20:46:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHAE5-0004r5-Iy for sip@ietf.org; Wed, 08 Mar 2006 20:46:01 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHAE5-0005r9-CS for sip@ietf.org; Wed, 08 Mar 2006 20:46:01 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k291jt7r064555; Wed, 8 Mar 2006 20:46:00 -0500 (EST) From: "Brett Tate" To: "'Paul Kyzivat'" Subject: RE: [Sip] The Problem with PRACK Date: Wed, 8 Mar 2006 20:46:59 -0500 Message-ID: <003401c6431b$5b004480$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <440F6BEC.2000604@cisco.com> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 > > One problem is that some devices don't support=20 > > receiving prack with an offer. >=20 > There are lots of things that some devices don't=20 > support. We call those cases BUGS. > > Which devices are those? For this situation, typically devices which implemented the draft = versions of 100rel before it finally required such support. And the operator of = the device desires to keep 100rel active (for UDP reasons) until upgrading. > > Thus the sender needs to handle PRACK 200 without SDP and handle a=20 > > failure response because of the sdp. >=20 > Are you suggesting that it is *legal* to: > - support PRACK > - not support PRACK with sdp? Nope, just mentioning some common interop problems. > > And if the UAS does not accept the offer, some vendors=20 > > return 488/606 type responses; others return 200=20 > > without SDP. > >=20 > > I prefer removing ability for prack to contain an offer. However=20 > > leaving it is ok if vendors who send it can deal with the typical=20 > > interop problems. >=20 > You only want to remove ability for it to contain an offer,=20 > but allow it to contain an answer? Or remove support for=20 > both offer and answer? I prefer removing ability for prack to contain an offer. > As I noted in earlier reply, if we were to do that, then=20 > how do you answer an offer that comes in a reliable=20 > provisional response? As I indicated my prior email, I have the same type of concerns. > Any change in this stuff has backward compatibility issues.=20 > It would require use of new option tags, and even more=20 > complex support than the existing situation does. If vendors have deployed requiring support of offer in PRACK, I agree = the changes might present some interoperability challenges. However the new = tag (if required) is not complex; the tag just indicates functionality = similar to 100rel without certain offer/answer requirements. It just means a = UAS can have reliability without some of the offer/answer headaches. However if all/most vendors currently do not require support of offer in PRACK, it might be acceptable to document the change without requiring a = new option tag. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 21:48:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHBB1-0003kU-MZ; Wed, 08 Mar 2006 21:46:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHBAz-0003jX-6L for sip@ietf.org; Wed, 08 Mar 2006 21:46:53 -0500 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 1FHBAx-0007EL-KG for sip@ietf.org; Wed, 08 Mar 2006 21:46:53 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2006 18:46:51 -0800 X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208"; a="413777912:sNHT34092144" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k292koGv016567; Wed, 8 Mar 2006 18:46:50 -0800 (PST) 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.211); Wed, 8 Mar 2006 21:46:50 -0500 Received: from [10.86.243.71] ([10.86.243.71]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 21:46:49 -0500 Message-ID: <440F9719.4050307@cisco.com> Date: Wed, 08 Mar 2006 21:46:49 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] The Problem with PRACK References: <440E5E52.20500@cisco.com> <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> In-Reply-To: <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 02:46:49.0763 (UTC) FILETIME=[B6DF1F30:01C64323] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 comment at end Rohan Mahy wrote: > Hi, > > A things about PRACK come immediately to mind that are a pain to implement: > > 1) The UAS has to queue provisionals until it receives a PRACK for the > first provisional. This is due to RSeq starting at an arbitrary value > instead of just starting at 1. This is probably the simplest to fix, by > just requiring the UAC to always start with a RSeq of 1. > > 2) Multiple unacknowledged provisionals can be in flight at the same > time. We could potentially eliminate this requirement by acknowledging > the current status instead of the whole history. In other words, when > the UAS sends a new reliable provisional, it decides which (if any) of > the previously sent provisionals are still relevant and sends all of > them (as sipfrags or something) as a single reliable request. > > 3) If you "answer" and want to deliver a 200 OK, you have to queue it > and wait if you are waiting for a PRACK to an offer or answer. Keeping > track of when you can send the 200 would be easier if we did something > like I recommend in #2. > > 4) Even for an acknowledged provisional, you still have to retransmit > approximately every minute (I forget exactly) to prevent old proxies > from deleting state for your transaction. This is one of those minor > annoyances that is *almost* operationally irrelevant, and unlikely to > not get coded. My proposal for simplification is to retransmit the > latest reliable provisional in exactly the same way that the UAS > retransmits unreliable provisionals. Who cares if there is an extra > message or two for a call with 1 minute + post-answer delay? > > 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I > talked Jonathan into this, and I've been sorry I did ever since. My > apologies to everyone for making a bad decision. As I mentioned elsewhere, if you deprecate this, then another way is needed to answer an offer that comes in a reliable provisional. The only obvious way would be to permit an answer in an UPDATE. In any case, any change like this must be accompanied by a some strategy for backward compatibility. This seems not so easy. As much as it is fun to imagine how it might have been done better the first time around, I suspect that at this point the cure is worse than the disease. Paul Paul > > Hope this helps. > thanks, > -rohan > > On 3/7/06, *Jonathan Rosenberg* > wrote: > > At the last IETF, there was a lot of discussion and argument around > PRACK. The spark of this debate was the ICE specification, which had > words in it requiring the usage of PRACK and UPDATE in order to work > with early media. There was strong pushback from many implementors that > anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) > that showed the state machine in his implementation resulting from > PRACK, and it was not pretty. > > So, I'd like to discuss exactly what IS the problem with PRACK? There > are really two pieces of state machinery in play here. One piece is the > complication that PRACK introduces into the offer/answer model. With > PRACK, you can now get a final answer in the 18x, and then send a new > offer in UPDATE, or even in PRACK itself. Another piece is the state > machinery with the retransmissions itself - correlating the PRACK with a > particular reliable provisional response and causing it to stop. > > In a chat with Flemming today, he suggested in interested remedy to our > PRACK dilemma. Why not revise PRACK so that you can't send an offer or > answer with it; it has no impact on the set of allowed O/A exchanges > defined by RFC 3261. I'm not sure if that would consequently break the > preconditions mechanism, but maybe there are some kind of offer/answer > limitations that would simplify things. > > So, this is one idea. I'd like for people who have complained about > PRACK implementations to speak up and indicate what exactly makes it so > complicated for them. > > 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 Mar 08 21:57:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHBJi-0002Se-1s; Wed, 08 Mar 2006 21:55:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHBJf-0002HA-7u for sip@ietf.org; Wed, 08 Mar 2006 21:55:51 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHBJe-0007aL-Ip for sip@ietf.org; Wed, 08 Mar 2006 21:55:51 -0500 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 k292pXj13588; Wed, 8 Mar 2006 21:51:33 -0500 (EST) Received: from [192.168.15.101] ([47.102.184.186] RDNS failed) by zrc2hxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 20:55:46 -0600 In-Reply-To: <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> References: <440E5E52.20500@cisco.com> <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <5FE1D0CB-60FE-45B2-8CF5-EC15897C2EE5@nortel.com> From: "Francois Audet" Subject: Re: [Sip] The Problem with PRACK Date: Wed, 8 Mar 2006 18:55:45 -0800 To: "Rohan Mahy" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 09 Mar 2006 02:55:46.0076 (UTC) FILETIME=[F689FDC0:01C64324] X-Spam-Score: 3.1 (+++) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 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="===============1822826764==" Errors-To: sip-bounces@ietf.org --===============1822826764== Content-Type: multipart/alternative; boundary=Apple-Mail-3-356987917 --Apple-Mail-3-356987917 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I'm ok with the suggestion to deprecate using PRACK for Offer/Answer. While we are at it, why not go for deprecating the use PRACK altogether when TCP transport is used? On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: > Hi, > > A things about PRACK come immediately to mind that are a pain to > implement: > > 1) The UAS has to queue provisionals until it receives a PRACK for > the first provisional. This is due to RSeq starting at an > arbitrary value instead of just starting at 1. This is probably > the simplest to fix, by just requiring the UAC to always start with > a RSeq of 1. > > 2) Multiple unacknowledged provisionals can be in flight at the > same time. We could potentially eliminate this requirement by > acknowledging the current status instead of the whole history. In > other words, when the UAS sends a new reliable provisional, it > decides which (if any) of the previously sent provisionals are > still relevant and sends all of them (as sipfrags or something) as > a single reliable request. > > 3) If you "answer" and want to deliver a 200 OK, you have to queue > it and wait if you are waiting for a PRACK to an offer or answer. > Keeping track of when you can send the 200 would be easier if we > did something like I recommend in #2. > > 4) Even for an acknowledged provisional, you still have to > retransmit approximately every minute (I forget exactly) to prevent > old proxies from deleting state for your transaction. This is one > of those minor annoyances that is *almost* operationally > irrelevant, and unlikely to not get coded. My proposal for > simplification is to retransmit the latest reliable provisional in > exactly the same way that the UAS retransmits unreliable > provisionals. Who cares if there is an extra message or two for a > call with 1 minute + post-answer delay? > > 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. > I talked Jonathan into this, and I've been sorry I did ever since. > My apologies to everyone for making a bad decision. > > Hope this helps. > thanks, > -rohan > > On 3/7/06, Jonathan Rosenberg wrote: > At the last IETF, there was a lot of discussion and argument around > PRACK. The spark of this debate was the ICE specification, which had > words in it requiring the usage of PRACK and UPDATE in order to work > with early media. There was strong pushback from many implementors > that > anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) > that showed the state machine in his implementation resulting from > PRACK, and it was not pretty. > > So, I'd like to discuss exactly what IS the problem with PRACK? There > are really two pieces of state machinery in play here. One piece is > the > complication that PRACK introduces into the offer/answer model. With > PRACK, you can now get a final answer in the 18x, and then send a new > offer in UPDATE, or even in PRACK itself. Another piece is the state > machinery with the retransmissions itself - correlating the PRACK > with a > particular reliable provisional response and causing it to stop. > > In a chat with Flemming today, he suggested in interested remedy to > our > PRACK dilemma. Why not revise PRACK so that you can't send an offer or > answer with it; it has no impact on the set of allowed O/A exchanges > defined by RFC 3261. I'm not sure if that would consequently break the > preconditions mechanism, but maybe there are some kind of offer/answer > limitations that would simplify things. > > So, this is one idea. I'd like for people who have complained about > PRACK implementations to speak up and indicate what exactly makes > it so > complicated for them. > > 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 --Apple-Mail-3-356987917 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
I'm ok with the suggestion = to deprecate using PRACK for Offer/Answer.=A0

While we are at it, why not = go for deprecating the use PRACK altogether when TCP transport is = used?


On Mar 8, 2006, at = 15:51 , Rohan Mahy wrote:

Hi,

A= things about PRACK come immediately to mind that are a pain to = implement:

1) The UAS has to queue provisionals until it receives = a PRACK for the first provisional.=A0 This is due to RSeq starting at an = arbitrary value instead of just starting at 1.=A0 This is probably the = simplest to fix, by just requiring the UAC to always start with a RSeq = of 1.

2) Multiple unacknowledged provisionals can be in flight = at the same time.=A0 We could potentially eliminate this requirement by = acknowledging the current status instead of the whole history.=A0 In = other words, when the UAS sends a new reliable provisional, it decides = which (if any) of the previously sent provisionals are still relevant = and sends all of them (as sipfrags or something) as a single reliable = request.

3) If you "answer" and want to deliver a 200 OK, you = have to queue it and wait if you are waiting for a PRACK to an offer or = answer. Keeping track of when you can send the 200 would be easier if we = did something like I recommend in #2.=A0

4) Even for an = acknowledged provisional, you still have to retransmit approximately = every minute (I forget exactly) to prevent old proxies from deleting = state for your transaction.=A0 This is one of those minor annoyances = that is *almost* operationally irrelevant, and unlikely to not get = coded.=A0 My proposal for simplification is to retransmit the latest = reliable provisional in exactly the same way that the UAS retransmits = unreliable provisionals.=A0 Who cares if there is an extra message or = two for a call with 1 minute + post-answer delay?

5) I would = deprecate the PRACK/200 (PRACK) offer/answer exchange.=A0 I talked = Jonathan into this, and I've been sorry I did ever since.=A0 My = apologies to everyone for making a bad decision.

Hope this = helps.
thanks,
-rohan

On = 3/7/06, Jonathan Rosenberg <jdrosen@cisco.com> = wrote:
At the last IETF, there was a lot of discussion and argument = around
PRACK. The spark of this debate was the ICE specification, = which had
words in it requiring the usage of PRACK and UPDATE in = order to work
with early media. There was strong pushback from many = implementors that
anything requiring PRACK is unacceptable. Rohan = put up a slide (IIRC)
that showed the state machine in his = implementation resulting from
PRACK, and it was not = pretty.

So, I'd like to discuss exactly what IS the problem with = PRACK? There
are really two pieces of state machinery in play here. = One piece is the
complication that PRACK introduces into the = offer/answer model. With
PRACK, you can now get a final answer in the = 18x, and then send a new
offer in UPDATE, or even in PRACK itself. = Another piece is the state
machinery with the retransmissions itself = - correlating the PRACK with a
particular reliable provisional = response and causing it to stop.

In a chat with Flemming today, = he suggested in interested remedy to our
PRACK dilemma. Why not = revise PRACK so that you can't send an offer or
answer with it; it = has no impact on the set of allowed O/A exchanges
defined by RFC = 3261. I'm not sure if that would consequently break the
= preconditions mechanism, but maybe there are some kind of = offer/answer
limitations that would simplify things.

So, this = is one idea. I'd like for people who have complained about
PRACK = implementations to speak up and indicate what exactly makes it so =
complicated for them.

Thanks,
Jonathan = R.
--
Jonathan D. Rosenberg, Ph.D.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 600 Lanidex Plaza
Cisco = Fellow=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Parsippany, NJ 07054-2711
Cisco = Systems
jdrosen@cisco.com=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0FAX:=A0= =A0 (973) 952-5050
http://www.jdrosen.net=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PHONE: (973) = 952-5000
http://www.cisco.com

____________= ___________________________________
Sip mailing list=A0=A0https://www1.ietf.org/= mailman/listinfo/sip
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

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-3-356987917-- --===============1822826764== 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 --===============1822826764==-- From sip-bounces@ietf.org Wed Mar 08 22:31:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHBq6-00068w-0H; Wed, 08 Mar 2006 22:29:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHBq4-00068r-Cv for sip@ietf.org; Wed, 08 Mar 2006 22:29:20 -0500 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 1FHBq2-0000fa-PZ for sip@ietf.org; Wed, 08 Mar 2006 22:29:20 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2006 19:29:18 -0800 X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208"; a="413785313:sNHT35942868" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k293TH7T022420; Wed, 8 Mar 2006 19:29:18 -0800 (PST) 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.211); Wed, 8 Mar 2006 22:29:17 -0500 Received: from [10.86.243.71] ([10.86.243.71]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 22:29:17 -0500 Message-ID: <440FA10C.2060500@cisco.com> Date: Wed, 08 Mar 2006 22:29:16 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] The Problem with PRACK References: <440E5E52.20500@cisco.com> <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> <5FE1D0CB-60FE-45B2-8CF5-EC15897C2EE5@nortel.com> In-Reply-To: <5FE1D0CB-60FE-45B2-8CF5-EC15897C2EE5@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 03:29:17.0135 (UTC) FILETIME=[A5393DF0:01C64329] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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: > I'm ok with the suggestion to deprecate using PRACK for Offer/Answer. > > While we are at it, why not go for deprecating the use PRACK altogether > when TCP transport is used? Explain to me again how you would know that reliable transport is used end to end? Paul > On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: > >> Hi, >> >> A things about PRACK come immediately to mind that are a pain to >> implement: >> >> 1) The UAS has to queue provisionals until it receives a PRACK for the >> first provisional. This is due to RSeq starting at an arbitrary value >> instead of just starting at 1. This is probably the simplest to fix, >> by just requiring the UAC to always start with a RSeq of 1. >> >> 2) Multiple unacknowledged provisionals can be in flight at the same >> time. We could potentially eliminate this requirement by >> acknowledging the current status instead of the whole history. In >> other words, when the UAS sends a new reliable provisional, it decides >> which (if any) of the previously sent provisionals are still relevant >> and sends all of them (as sipfrags or something) as a single reliable >> request. >> >> 3) If you "answer" and want to deliver a 200 OK, you have to queue it >> and wait if you are waiting for a PRACK to an offer or answer. Keeping >> track of when you can send the 200 would be easier if we did something >> like I recommend in #2. >> >> 4) Even for an acknowledged provisional, you still have to retransmit >> approximately every minute (I forget exactly) to prevent old proxies >> from deleting state for your transaction. This is one of those minor >> annoyances that is *almost* operationally irrelevant, and unlikely to >> not get coded. My proposal for simplification is to retransmit the >> latest reliable provisional in exactly the same way that the UAS >> retransmits unreliable provisionals. Who cares if there is an extra >> message or two for a call with 1 minute + post-answer delay? >> >> 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I >> talked Jonathan into this, and I've been sorry I did ever since. My >> apologies to everyone for making a bad decision. >> >> Hope this helps. >> thanks, >> -rohan >> >> On 3/7/06, *Jonathan Rosenberg* > > wrote: >> >> At the last IETF, there was a lot of discussion and argument around >> PRACK. The spark of this debate was the ICE specification, which had >> words in it requiring the usage of PRACK and UPDATE in order to work >> with early media. There was strong pushback from many implementors >> that >> anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) >> that showed the state machine in his implementation resulting from >> PRACK, and it was not pretty. >> >> So, I'd like to discuss exactly what IS the problem with PRACK? There >> are really two pieces of state machinery in play here. One piece >> is the >> complication that PRACK introduces into the offer/answer model. With >> PRACK, you can now get a final answer in the 18x, and then send a new >> offer in UPDATE, or even in PRACK itself. Another piece is the state >> machinery with the retransmissions itself - correlating the PRACK >> with a >> particular reliable provisional response and causing it to stop. >> >> In a chat with Flemming today, he suggested in interested remedy >> to our >> PRACK dilemma. Why not revise PRACK so that you can't send an offer or >> answer with it; it has no impact on the set of allowed O/A exchanges >> defined by RFC 3261. I'm not sure if that would consequently break the >> preconditions mechanism, but maybe there are some kind of offer/answer >> limitations that would simplify things. >> >> So, this is one idea. I'd like for people who have complained about >> PRACK implementations to speak up and indicate what exactly makes >> it so >> complicated for them. >> >> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 08 23:09:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHCRO-0006Rt-Mn; Wed, 08 Mar 2006 23:07:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHCRN-0006Ro-RQ for sip@ietf.org; Wed, 08 Mar 2006 23:07:53 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHCRJ-0001bo-45 for sip@ietf.org; Wed, 08 Mar 2006 23:07:53 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 08 Mar 2006 20:07:48 -0800 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 k2947mGv017474; Wed, 8 Mar 2006 20:07:48 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 20:07:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] The Problem with PRACK Date: Wed, 8 Mar 2006 20:05:35 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB014128AA@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDE2S9Uw7HnI7DRM2AObg6DmaTWQAGpO1Q From: "Arunachalam Venkatraman \(arunvenk\)" To: "Rohan Mahy" , "Jonathan Rosenberg \(jdrosen\)" X-OriginalArrivalTime: 09 Mar 2006 04:07:48.0271 (UTC) FILETIME=[06C49BF0:01C6432F] X-Spam-Score: 0.1 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b 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="===============0797438655==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0797438655== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6432F.0679D879" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6432F.0679D879 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding 1 below about having to queue up provisionals pending PRACK for first one, an additional nuance is that it is also required to queue up provisionals even after the first is PRACKed and send them one at a time, as the PRACK for each is received. If this were not done, then the PRACKS may be received out of sequence and mess up the CSeq check for requests received at the UAS. Then the UAS will futilely continue to retransmit the provisionals with no hope of ever matching the PRACKS that were returned a 500 response due to out-of-sequence receipt. ________________________________ From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 Sent: Wednesday, March 08, 2006 5:51 PM To: Jonathan Rosenberg (jdrosen) Cc: IETF SIP List Subject: Re: [Sip] The Problem with PRACK Hi, A things about PRACK come immediately to mind that are a pain to implement: 1) The UAS has to queue provisionals until it receives a PRACK for the first provisional. This is due to RSeq starting at an arbitrary value instead of just starting at 1. This is probably the simplest to fix, by just requiring the UAC to always start with a RSeq of 1.=20 2) Multiple unacknowledged provisionals can be in flight at the same time. We could potentially eliminate this requirement by acknowledging the current status instead of the whole history. In other words, when the UAS sends a new reliable provisional, it decides which (if any) of the previously sent provisionals are still relevant and sends all of them (as sipfrags or something) as a single reliable request.=20 3) If you "answer" and want to deliver a 200 OK, you have to queue it and wait if you are waiting for a PRACK to an offer or answer. Keeping track of when you can send the 200 would be easier if we did something like I recommend in #2. =20 4) Even for an acknowledged provisional, you still have to retransmit approximately every minute (I forget exactly) to prevent old proxies from deleting state for your transaction. This is one of those minor annoyances that is *almost* operationally irrelevant, and unlikely to not get coded. My proposal for simplification is to retransmit the latest reliable provisional in exactly the same way that the UAS retransmits unreliable provisionals. Who cares if there is an extra message or two for a call with 1 minute + post-answer delay?=20 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I talked Jonathan into this, and I've been sorry I did ever since. My apologies to everyone for making a bad decision. Hope this helps. thanks, -rohan On 3/7/06, Jonathan Rosenberg wrote:=20 At the last IETF, there was a lot of discussion and argument around PRACK. The spark of this debate was the ICE specification, which had words in it requiring the usage of PRACK and UPDATE in order to work with early media. There was strong pushback from many implementors that=20 anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) that showed the state machine in his implementation resulting from PRACK, and it was not pretty. =09 So, I'd like to discuss exactly what IS the problem with PRACK? There=20 are really two pieces of state machinery in play here. One piece is the complication that PRACK introduces into the offer/answer model. With PRACK, you can now get a final answer in the 18x, and then send a new offer in UPDATE, or even in PRACK itself. Another piece is the state machinery with the retransmissions itself - correlating the PRACK with a particular reliable provisional response and causing it to stop. =09 In a chat with Flemming today, he suggested in interested remedy to our=20 PRACK dilemma. Why not revise PRACK so that you can't send an offer or answer with it; it has no impact on the set of allowed O/A exchanges defined by RFC 3261. I'm not sure if that would consequently break the preconditions mechanism, but maybe there are some kind of offer/answer limitations that would simplify things. =09 So, this is one idea. I'd like for people who have complained about PRACK implementations to speak up and indicate what exactly makes it so=20 complicated for them. =09 Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems=20 jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C6432F.0679D879 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Regarding 1 below about having to queue up = provisionals=20 pending PRACK for first one, an additional nuance is that it is also = required to=20 queue up provisionals even after the first is PRACKed and send them one = at a=20 time, as the PRACK for each is received.
If this were not done, then the PRACKS may be = received out=20 of sequence and mess up the CSeq check for requests received = at the=20 UAS.
Then the UAS will futilely continue = to retransmit the=20 provisionals with no hope of ever matching the PRACKS that were = returned a=20 500 response due to out-of-sequence receipt.

From: Rohan Mahy = [mailto:rohan.mahy@gmail.com]=20
Sent: Wednesday, March 08, 2006 5:51 PM
To: = Jonathan=20 Rosenberg (jdrosen)
Cc: IETF SIP List
Subject: Re: = [Sip] The=20 Problem with PRACK

Hi,

A things about PRACK come immediately to mind that = are a=20 pain to implement:

1) The UAS has to queue provisionals until it = receives=20 a PRACK for the first provisional.  This is due to RSeq starting at = an=20 arbitrary value instead of just starting at 1.  This is probably = the=20 simplest to fix, by just requiring the UAC to always start with a RSeq = of 1.=20

2) Multiple unacknowledged provisionals can be in flight at the = same=20 time.  We could potentially eliminate this requirement by = acknowledging the=20 current status instead of the whole history.  In other words, when = the UAS=20 sends a new reliable provisional, it decides which (if any) of the = previously=20 sent provisionals are still relevant and sends all of them (as sipfrags = or=20 something) as a single reliable request.

3) If you "answer" and = want to=20 deliver a 200 OK, you have to queue it and wait if you are waiting for a = PRACK=20 to an offer or answer. Keeping track of when you can send the 200 would = be=20 easier if we did something like I recommend in #2. 

4) Even = for an=20 acknowledged provisional, you still have to retransmit approximately = every=20 minute (I forget exactly) to prevent old proxies from deleting state for = your=20 transaction.  This is one of those minor annoyances that is = *almost*=20 operationally irrelevant, and unlikely to not get coded.  My = proposal for=20 simplification is to retransmit the latest reliable provisional in = exactly the=20 same way that the UAS retransmits unreliable provisionals.  Who = cares if=20 there is an extra message or two for a call with 1 minute + post-answer = delay?=20

5) I would deprecate the PRACK/200 (PRACK) offer/answer = exchange. =20 I talked Jonathan into this, and I've been sorry I did ever since.  = My=20 apologies to everyone for making a bad decision.

Hope this=20 helps.
thanks,
-rohan

On 3/7/06, Jonathan=20 Rosenberg <jdrosen@cisco.com>=20 wrote:
At=20 the last IETF, there was a lot of discussion and argument = around
PRACK. The=20 spark of this debate was the ICE specification, which had
words in = it=20 requiring the usage of PRACK and UPDATE in order to work
with early = media.=20 There was strong pushback from many implementors that
anything = requiring=20 PRACK is unacceptable. Rohan put up a slide (IIRC)
that showed the = state=20 machine in his implementation resulting from
PRACK, and it was not=20 pretty.

So, I'd like to discuss exactly what IS the problem = with PRACK?=20 There
are really two pieces of state machinery in play here. One = piece is=20 the
complication that PRACK introduces into the offer/answer model. = With
PRACK, you can now get a final answer in the 18x, and then = send a=20 new
offer in UPDATE, or even in PRACK itself. Another piece is the=20 state
machinery with the retransmissions itself - correlating the = PRACK=20 with a
particular reliable provisional response and causing it to=20 stop.

In a chat with Flemming today, he suggested in interested = remedy=20 to our
PRACK dilemma. Why not revise PRACK so that you can't send = an offer=20 or
answer with it; it has no impact on the set of allowed O/A=20 exchanges
defined by RFC 3261. I'm not sure if that would = consequently=20 break the
preconditions mechanism, but maybe there are some kind of = offer/answer
limitations that would simplify things.

So, = this is one=20 idea. I'd like for people who have complained about
PRACK = implementations=20 to speak up and indicate what exactly makes it so
complicated for=20 them.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg,=20 = Ph.D.           &n= bsp;      =20 600 Lanidex Plaza
Cisco=20 = Fellow           &= nbsp;           &n= bsp;          =20 Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com   =             &= nbsp;           &n= bsp;  FAX:  =20 (973) 952-5050
http://www.jdrosen.net  &nb= sp;           &nbs= p;         =20 PHONE: (973) 952-5000
http://www.cisco.com

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

------_=_NextPart_001_01C6432F.0679D879-- --===============0797438655== 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 --===============0797438655==-- From sip-bounces@ietf.org Thu Mar 09 00:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHDFl-0007j6-AC; Wed, 08 Mar 2006 23:59:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHDFk-0007id-3b for sip@ietf.org; Wed, 08 Mar 2006 23:59:56 -0500 Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHDFg-0002qq-SY for sip@ietf.org; Wed, 08 Mar 2006 23:59:55 -0500 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id k294xVZ13920; Thu, 9 Mar 2006 10:29:31 +0530 In-Reply-To: <440F199F.2060007@alcatel.fr> Subject: Re: [Sip] Outbound and GRUU, To: Thomas.Levy@alcatel.fr X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: vikram.agarwal@flextronicssoftware.com Date: Thu, 9 Mar 2006 10:29:29 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 03/09/2006 10:29:56 AM MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: fluffy@cisco.com, rohan@ekabal.com, 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="===============0679625477==" Errors-To: sip-bounces@ietf.org --===============0679625477== Content-type: multipart/related; Boundary="0__=EABBFBBFDF8892678f9e8a93df938690918cEABBFBBFDF889267" Content-Disposition: inline --0__=EABBFBBFDF8892678f9e8a93df938690918cEABBFBBFDF889267 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: base64 PGh0bWw+PGJvZHk+DQo8cD48YnI+DQpIaSBUaG9tYXMsPGJyPg0KPGJyPg0KICAgVGhlIGluc3Rh bmNlLWlkIGlzIG1hbmRhdG9yeSBiZWNhdXNlIGl0IGlkZW50aWZpZXMgYSBzcGVjaWZpYyBkZXZp Y2UgdG8gd2hpY2ggdGhlIG1lc3NhZ2Ugc2hvdWxkIGJlIHJvdXRlZC4gVGhlcmUgY2FuIGJlIG11 bHRpcGxlIGNvbm5lY3Rpb25zIHRvIGEgZGV2aWNlLCBoZW5jZSB0byBpZGVudGlmeSBhIGNvbm5l Y3Rpb24gdGhlIGZsb3ctaWQgY29tZXMgaW50byBlZmZlY3QuIEJ1dCwgbm93IHRoZSBxdWVzdGlv biBpcyBHUlVVIGNhbiBiZSBib3VuZGVkIHRvIG9ubHkgb25lIGNvbnRhY3QgaS5lLiBBT1IvY29u dGFjdCBwYWlyLiBIZW5jZSwgdGhlIG91dGVyIHdvcmxkIGNhbiByZWFjaCBHUlVVLCBpLmUuIG9u ZSBjb250YWN0IG9mIGEgZGV2aWNlLCBpLmUuIG9ubHkgb25lIGNvbm5lY3Rpb24uIEluIHRoaXMg Y2FzZSB3ZSB3b3VsZG4ndCByZXF1aXJlIHRoZSBmbG93LWlkIHBhcmFtZXRlci4gT25seSwgdGhl IGluc3RhbmNlLWlkIHdvdWxkIGJlIHN1ZmZpY2llbnQgdG8gcm91dGUgdGhlIGNhbGwgYmFzZWQg b24gdGhlIGluc3RhbmNlLWlkLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KLS1WaWtyYW0uPGJy Pg0KICAgPGJyPg0KPGltZyBzcmM9ImNpZDowMF9fPUVBQkJGQkJGREY4ODkyNjdAZmxleHRyb25p Y3Nzb2Z0d2FyZS5jb20iIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiIgYWx0PSJJbmFjdGl2ZSBoaWRl IGRldGFpbHMgZm9yIFRob21hcy5MZXZ5QGFsY2F0ZWwuZnIiPlRob21hcy5MZXZ5QGFsY2F0ZWwu ZnI8YnI+DQo8YnI+DQo8YnI+DQoNCjx0YWJsZSB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRyIHZhbGlnbj0idG9wIj48dGQgc3R5bGU9 ImJhY2tncm91bmQtaW1hZ2U6dXJsKGNpZDoxMF9fPUVBQkJGQkJGREY4ODkyNjdAZmxleHRyb25p Y3Nzb2Z0d2FyZS5jb20pOyBiYWNrZ3JvdW5kLXJlcGVhdDogbm8tcmVwZWF0OyAiIHdpZHRoPSI0 MCUiPg0KPHVsPg0KPHVsPg0KPHVsPg0KPHVsPjxiPjxmb250IHNpemU9IjIiPlRob21hcy5MZXZ5 QGFsY2F0ZWwuZnI8L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiPiA8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPSIyIj4wMy8wOC8yMDA2IDExOjIxIFBNPC9mb250PjwvdWw+DQo8L3VsPg0KPC91bD4NCjwv dWw+DQo8L3RkPjx0ZCB3aWR0aD0iNjAlIj4NCjx0YWJsZSB3aWR0aD0iMTAwJSIgYm9yZGVyPSIw IiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRyIHZhbGlnbj0idG9wIj48dGQg d2lkdGg9IjElIiB2YWxpZ249Im1pZGRsZSI+PGltZyBzcmM9ImNpZDoyMF9fPUVBQkJGQkJGREY4 ODkyNjdAZmxleHRyb25pY3Nzb2Z0d2FyZS5jb20iIGJvcmRlcj0iMCIgaGVpZ2h0PSIxIiB3aWR0 aD0iNTgiIGFsdD0iIj48YnI+DQo8ZGl2IGFsaWduPSJyaWdodCI+PGZvbnQgc2l6ZT0iMiI+VG88 L2ZvbnQ+PC9kaXY+PC90ZD48dGQgd2lkdGg9IjEwMCUiPjxpbWcgc3JjPSJjaWQ6MjBfXz1FQUJC RkJCRkRGODg5MjY3QGZsZXh0cm9uaWNzc29mdHdhcmUuY29tIiBib3JkZXI9IjAiIGhlaWdodD0i MSIgd2lkdGg9IjEiIGFsdD0iIj48YnI+DQo8Zm9udCBzaXplPSIyIj5mbHVmZnlAY2lzY28uY29t LCByb2hhbkBla2FiYWwuY29tPC9mb250PjwvdGQ+PC90cj4NCg0KPHRyIHZhbGlnbj0idG9wIj48 dGQgd2lkdGg9IjElIiB2YWxpZ249Im1pZGRsZSI+PGltZyBzcmM9ImNpZDoyMF9fPUVBQkJGQkJG REY4ODkyNjdAZmxleHRyb25pY3Nzb2Z0d2FyZS5jb20iIGJvcmRlcj0iMCIgaGVpZ2h0PSIxIiB3 aWR0aD0iNTgiIGFsdD0iIj48YnI+DQo8ZGl2IGFsaWduPSJyaWdodCI+PGZvbnQgc2l6ZT0iMiI+ Y2M8L2ZvbnQ+PC9kaXY+PC90ZD48dGQgd2lkdGg9IjEwMCUiPjxpbWcgc3JjPSJjaWQ6MjBfXz1F QUJCRkJCRkRGODg5MjY3QGZsZXh0cm9uaWNzc29mdHdhcmUuY29tIiBib3JkZXI9IjAiIGhlaWdo dD0iMSIgd2lkdGg9IjEiIGFsdD0iIj48YnI+DQo8Zm9udCBzaXplPSIyIj5zaXBAaWV0Zi5vcmc8 L2ZvbnQ+PC90ZD48L3RyPg0KDQo8dHIgdmFsaWduPSJ0b3AiPjx0ZCB3aWR0aD0iMSUiIHZhbGln bj0ibWlkZGxlIj48aW1nIHNyYz0iY2lkOjIwX189RUFCQkZCQkZERjg4OTI2N0BmbGV4dHJvbmlj c3NvZnR3YXJlLmNvbSIgYm9yZGVyPSIwIiBoZWlnaHQ9IjEiIHdpZHRoPSI1OCIgYWx0PSIiPjxi cj4NCjxkaXYgYWxpZ249InJpZ2h0Ij48Zm9udCBzaXplPSIyIj5TdWJqZWN0PC9mb250PjwvZGl2 PjwvdGQ+PHRkIHdpZHRoPSIxMDAlIj48aW1nIHNyYz0iY2lkOjIwX189RUFCQkZCQkZERjg4OTI2 N0BmbGV4dHJvbmljc3NvZnR3YXJlLmNvbSIgYm9yZGVyPSIwIiBoZWlnaHQ9IjEiIHdpZHRoPSIx IiBhbHQ9IiI+PGJyPg0KPGZvbnQgc2l6ZT0iMiI+W1NpcF0gT3V0Ym91bmQgYW5kIEdSVVUsPC9m b250PjwvdGQ+PC90cj4NCjwvdGFibGU+DQoNCjx0YWJsZSBib3JkZXI9IjAiIGNlbGxzcGFjaW5n PSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dHIgdmFsaWduPSJ0b3AiPjx0ZCB3aWR0aD0iNTgiPjxp bWcgc3JjPSJjaWQ6MjBfXz1FQUJCRkJCRkRGODg5MjY3QGZsZXh0cm9uaWNzc29mdHdhcmUuY29t IiBib3JkZXI9IjAiIGhlaWdodD0iMSIgd2lkdGg9IjEiIGFsdD0iIj48L3RkPjx0ZCB3aWR0aD0i MzM2Ij48aW1nIHNyYz0iY2lkOjIwX189RUFCQkZCQkZERjg4OTI2N0BmbGV4dHJvbmljc3NvZnR3 YXJlLmNvbSIgYm9yZGVyPSIwIiBoZWlnaHQ9IjEiIHdpZHRoPSIxIiBhbHQ9IiI+PC90ZD48L3Ry Pg0KPC90YWJsZT4NCjwvdGQ+PC90cj4NCjwvdGFibGU+DQo8YnI+DQo8dHQ+Q3VsbGVuIGFuZCBS b2hhbiw8YnI+DQo8YnI+DQpDb3VsZCB5b3UgcHJvdmlkZSBleHBsYW5hdGlvbnMgb24gcmVsYXRp b24gYmV0d2VlbiBPdXRib3VuZCBhbmQgR1JVVS48YnI+DQpJbiBmYWN0LCBJIGRpZG4ndCBmb2xs b3cgd2hvbGUgdGhlIHRocmVhZHMgY29uY2VybmluZyB0aGUgT3V0Ym91bmQgPGJyPg0KZHJhZnQs IHBlcmhhcHMgaXQgbWF5IGV4cGxhaW4gbXkgcXVlc3Rpb24uPGJyPg0KSG93ZXZlciwgY291bGQg eW91IGFuc3dlciB0aGUgZm9sbG93aW5nIHBvaW50czo8YnI+DQpJbiBteSB1bmRlcnN0YW5kaW5n LCBHUlVVIGlzIHVzZWZ1bCB3aGVuIGFuIEFPUiBtYXkgYmUgcmVnaXN0ZXJlZCA8YnI+DQpzaW11 bHRhbmVvdXNseSBvbiBtdWx0aXBsZSBVQSBpbnN0YW5jZXMuPGJyPg0KSG93ZXZlciwgdGhlIHNj b3BlIChhbmQgcmVxdWlyZW1lbnRzKSBmcm9tIE91dGJvdW5kIHNlZW0gZGlmZmVyZW50Ljxicj4N ClNvLCB3aGF0IGFyZSB0aGUgbW90aXZhdGlvbnMgZm9yIG1ha2luZyBvdXRib3VuZCBmdWxseSBk ZXBlbmRlbnQgZnJvbSBHUlVVPzxicj4NCkZvciBpbnN0YW5jZSwgaW4gbXkgb3BpbmlvbiwgYSB1 c2VyIHJlZ2lzdGVyZWQgb24gYSBuYXR0ZWQgVUEgY291bGQgdXNlIDxicj4NCm91dGJvdW5kIChh bmQgdGh1cyBoYXZlIGEgcGVyc2lzdGVudCBjb25uZWN0aW9uIHdpdGggaXRzIHByb3h5KSB3aXRo b3V0IDxicj4NCmhhdmluZyBhbiBpbnN0YW5jZSBJRC48YnI+DQpXaHkgaXMgaXQgbWFuZGF0b3J5 IGZvciBhIFVBIHRvIGhhdmUgYW4gSW5zdGFuY2UgSUQgKGFzIGV4cGxhaW5lZCBpbiA8YnI+DQpz ZWN0aW9uIDQuMSkgZm9yIG91dGJvdW5kPzxicj4NCjxicj4NClRoYW5rcyBmb3IgeW91ciBoZWxw Ljxicj4NCjxicj4NClRob21hcyBMRVZZPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTaXAgbWFpbGluZyBsaXN0ICZuYnNwOzwv dHQ+PHR0PjxhIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cCI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwPC9hPjwvdHQ+PHR0 Pjxicj4NClRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQ cm90b2NvbDxicj4NClVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVl c3Rpb25zIG9uIGN1cnJlbnQgc2lwPGJyPg0KVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBk ZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcDxicj4NCjwvdHQ+PGJyPg0KPGJy Pg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKiogIEZTUy1VbmNsYXNzaWZpZWQgICAqKioq KioqKioqKioqKioqKioqKioqKjwvYm9keT48L2h0bWw+ --0__=EABBFBBFDF8892678f9e8a93df938690918cEABBFBBFDF889267 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <00__=EABBFBBFDF889267@flextronicssoftware.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=EABBFBBFDF8892678f9e8a93df938690918cEABBFBBFDF889267 Content-type: image/gif; name="pic18401.gif" Content-Disposition: inline; filename="pic18401.gif" Content-ID: <10__=EABBFBBFDF889267@flextronicssoftware.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=EABBFBBFDF8892678f9e8a93df938690918cEABBFBBFDF889267 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=EABBFBBFDF889267@flextronicssoftware.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=EABBFBBFDF8892678f9e8a93df938690918cEABBFBBFDF889267-- --===============0679625477== 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 --===============0679625477==-- From sip-bounces@ietf.org Thu Mar 09 02:21:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHFQU-0006E8-Ko; Thu, 09 Mar 2006 02:19:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHFQS-000679-Vs for sip@ietf.org; Thu, 09 Mar 2006 02:19:08 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHFQP-0006jc-Cy for sip@ietf.org; Thu, 09 Mar 2006 02:19:08 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k297J1F25045; Thu, 9 Mar 2006 02:19:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Thu, 9 Mar 2006 01:18:57 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AC93F68@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDKbTdkK7rzamkTDilDZQKBR4mhAAH2J5A From: "Samir Srivastava" To: "Paul Kyzivat" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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 We can do for SIPS only. Thx Samir=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Wednesday, March 08, 2006 7:29 PM To: Audet, Francois [SC100:3055:EXCH] Cc: IETF SIP List Subject: Re: [Sip] The Problem with PRACK Francois Audet wrote: > I'm ok with the suggestion to deprecate using PRACK for Offer/Answer.=20 >=20 > While we are at it, why not go for deprecating the use PRACK=20 > altogether when TCP transport is used? Explain to me again how you would know that reliable transport is used end to end? Paul > On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: >=20 >> Hi, >> >> A things about PRACK come immediately to mind that are a pain to >> implement: >> >> 1) The UAS has to queue provisionals until it receives a PRACK for=20 >> the first provisional. This is due to RSeq starting at an arbitrary=20 >> value instead of just starting at 1. This is probably the simplest=20 >> to fix, by just requiring the UAC to always start with a RSeq of 1. >> >> 2) Multiple unacknowledged provisionals can be in flight at the same=20 >> time. We could potentially eliminate this requirement by=20 >> acknowledging the current status instead of the whole history. In=20 >> other words, when the UAS sends a new reliable provisional, it=20 >> decides which (if any) of the previously sent provisionals are still=20 >> relevant and sends all of them (as sipfrags or something) as a single >> reliable request. >> >> 3) If you "answer" and want to deliver a 200 OK, you have to queue it >> and wait if you are waiting for a PRACK to an offer or answer.=20 >> Keeping track of when you can send the 200 would be easier if we did=20 >> something like I recommend in #2. >> >> 4) Even for an acknowledged provisional, you still have to retransmit >> approximately every minute (I forget exactly) to prevent old proxies=20 >> from deleting state for your transaction. This is one of those minor >> annoyances that is *almost* operationally irrelevant, and unlikely to >> not get coded. My proposal for simplification is to retransmit the=20 >> latest reliable provisional in exactly the same way that the UAS=20 >> retransmits unreliable provisionals. Who cares if there is an extra=20 >> message or two for a call with 1 minute + post-answer delay? >> >> 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I=20 >> talked Jonathan into this, and I've been sorry I did ever since. My=20 >> apologies to everyone for making a bad decision. >> >> Hope this helps. >> thanks, >> -rohan >> >> On 3/7/06, *Jonathan Rosenberg* > > wrote: >> >> At the last IETF, there was a lot of discussion and argument around >> PRACK. The spark of this debate was the ICE specification, which had >> words in it requiring the usage of PRACK and UPDATE in order to work >> with early media. There was strong pushback from many implementors >> that >> anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) >> that showed the state machine in his implementation resulting from >> PRACK, and it was not pretty. >> >> So, I'd like to discuss exactly what IS the problem with PRACK? There >> are really two pieces of state machinery in play here. One piece >> is the >> complication that PRACK introduces into the offer/answer model. With >> PRACK, you can now get a final answer in the 18x, and then send a new >> offer in UPDATE, or even in PRACK itself. Another piece is the state >> machinery with the retransmissions itself - correlating the PRACK >> with a >> particular reliable provisional response and causing it to stop. >> >> In a chat with Flemming today, he suggested in interested remedy >> to our >> PRACK dilemma. Why not revise PRACK so that you can't send an offer or >> answer with it; it has no impact on the set of allowed O/A exchanges >> defined by RFC 3261. I'm not sure if that would consequently break the >> preconditions mechanism, but maybe there are some kind of offer/answer >> limitations that would simplify things. >> >> So, this is one idea. I'd like for people who have complained about >> PRACK implementations to speak up and indicate what exactly makes >> it so >> complicated for them. >> >> Thanks, >> Jonathan R. >> -- >> 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 >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on current sip >> Use sipping@ietf.org for new >> developments on the application 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=20 >> for questions on current=20 >> sip Use sipping@ietf.org for new=20 >> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 02:38:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHFgy-0001QE-Tt; Thu, 09 Mar 2006 02:36:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHFgw-0001L3-SQ for sip@ietf.org; Thu, 09 Mar 2006 02:36:10 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHFgs-0007GE-RQ for sip@ietf.org; Thu, 09 Mar 2006 02:36:10 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k297a2ar008678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Mar 2006 08:36:02 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k297Zvfx015034; Thu, 9 Mar 2006 08:35:57 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k297Zlvw015032; Thu, 9 Mar 2006 08:35:47 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 From: Hans Persson To: Dean Willis In-Reply-To: <37FFEC27-3672-4AE7-B4A5-7E003C45B797@softarmor.com> References: <1141718155.10301.14.camel@eeek.ingate.se> <37FFEC27-3672-4AE7-B4A5-7E003C45B797@softarmor.com> Content-Type: text/plain; charset=iso-8859-4 Content-Transfer-Encoding: quoted-printable Organization: Ingate Systems Date: Thu, 09 Mar 2006 08:35:47 +0100 Message-Id: <1141889747.14635.5.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Thu, 09 Mar 2006 08:36:02 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 tis 2006-03-07 klockan 11:54 -0600 skrev Dean Willis: > > Both these functions are nice in an ideal world, but many people=20 > > will have SBCs, B2BUAs, or SIP-aware firewalls in their call paths. > > These will modify SDP and probably the Contact header. > > > > As far as I can see there is no discussion in the draft about this=20 > > at all, apart from the probably na=B5ve assumption that it shouldn't =20 > > happen. >=20 > That's because IT SHOULDN'T HAPPEN. >=20 > A B2BUA is NOT A proxy, and is NOT, in general, identity-transparent No, it shouldn't happen. I'm just saying that it will, in reality. I think it would be a good idea if new specs state explicitly if they are going to break in common deployment scenario types instead of just pretending that no problem exists. Hans --=20 Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 02:51:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHFtg-000795-1p; Thu, 09 Mar 2006 02:49:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHFtd-00076b-J5 for sip@ietf.org; Thu, 09 Mar 2006 02:49:17 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHFtT-0007Xc-Jt for sip@ietf.org; Thu, 09 Mar 2006 02:49:13 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k297int12851; Thu, 9 Mar 2006 02:44:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Thu, 9 Mar 2006 01:48:59 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AC93F70@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDKbTdkK7rzamkTDilDZQKBR4mhAAH2J5AAADO7yA= From: "Samir Srivastava" To: "Samir Srivastava" , "Paul Kyzivat" , "Francois Audet" X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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 We can do it, by adding more logic / header. UAS knows about all the hops by complete via header set inspection. When sending 1xx, it need to indicate in this new header to be defined. Is it worth defining this ? Thx Samir -----Original Message----- From: Srivastava, Samir [SC100:8826:EXCH]=20 Sent: Wednesday, March 08, 2006 11:19 PM To: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH] Cc: IETF SIP List Subject: RE: [Sip] The Problem with PRACK We can do for SIPS only. Thx Samir=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Wednesday, March 08, 2006 7:29 PM To: Audet, Francois [SC100:3055:EXCH] Cc: IETF SIP List Subject: Re: [Sip] The Problem with PRACK Francois Audet wrote: > I'm ok with the suggestion to deprecate using PRACK for Offer/Answer.=20 >=20 > While we are at it, why not go for deprecating the use PRACK=20 > altogether when TCP transport is used? Explain to me again how you would know that reliable transport is used end to end? Paul > On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: >=20 >> Hi, >> >> A things about PRACK come immediately to mind that are a pain to >> implement: >> >> 1) The UAS has to queue provisionals until it receives a PRACK for=20 >> the first provisional. This is due to RSeq starting at an arbitrary=20 >> value instead of just starting at 1. This is probably the simplest=20 >> to fix, by just requiring the UAC to always start with a RSeq of 1. >> >> 2) Multiple unacknowledged provisionals can be in flight at the same=20 >> time. We could potentially eliminate this requirement by=20 >> acknowledging the current status instead of the whole history. In=20 >> other words, when the UAS sends a new reliable provisional, it=20 >> decides which (if any) of the previously sent provisionals are still=20 >> relevant and sends all of them (as sipfrags or something) as a single >> reliable request. >> >> 3) If you "answer" and want to deliver a 200 OK, you have to queue it >> and wait if you are waiting for a PRACK to an offer or answer.=20 >> Keeping track of when you can send the 200 would be easier if we did=20 >> something like I recommend in #2. >> >> 4) Even for an acknowledged provisional, you still have to retransmit >> approximately every minute (I forget exactly) to prevent old proxies=20 >> from deleting state for your transaction. This is one of those minor >> annoyances that is *almost* operationally irrelevant, and unlikely to >> not get coded. My proposal for simplification is to retransmit the=20 >> latest reliable provisional in exactly the same way that the UAS=20 >> retransmits unreliable provisionals. Who cares if there is an extra=20 >> message or two for a call with 1 minute + post-answer delay? >> >> 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I=20 >> talked Jonathan into this, and I've been sorry I did ever since. My=20 >> apologies to everyone for making a bad decision. >> >> Hope this helps. >> thanks, >> -rohan >> >> On 3/7/06, *Jonathan Rosenberg* > > wrote: >> >> At the last IETF, there was a lot of discussion and argument around >> PRACK. The spark of this debate was the ICE specification, which had >> words in it requiring the usage of PRACK and UPDATE in order to work >> with early media. There was strong pushback from many implementors >> that >> anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) >> that showed the state machine in his implementation resulting from >> PRACK, and it was not pretty. >> >> So, I'd like to discuss exactly what IS the problem with PRACK? There >> are really two pieces of state machinery in play here. One piece >> is the >> complication that PRACK introduces into the offer/answer model. With >> PRACK, you can now get a final answer in the 18x, and then send a new >> offer in UPDATE, or even in PRACK itself. Another piece is the state >> machinery with the retransmissions itself - correlating the PRACK >> with a >> particular reliable provisional response and causing it to stop. >> >> In a chat with Flemming today, he suggested in interested remedy >> to our >> PRACK dilemma. Why not revise PRACK so that you can't send an offer or >> answer with it; it has no impact on the set of allowed O/A exchanges >> defined by RFC 3261. I'm not sure if that would consequently break the >> preconditions mechanism, but maybe there are some kind of offer/answer >> limitations that would simplify things. >> >> So, this is one idea. I'd like for people who have complained about >> PRACK implementations to speak up and indicate what exactly makes >> it so >> complicated for them. >> >> Thanks, >> Jonathan R. >> -- >> 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 >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on current sip >> Use sipping@ietf.org for new >> developments on the application 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=20 >> for questions on current=20 >> sip Use sipping@ietf.org for new=20 >> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 04:26:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHHOB-0006ZF-Qb; Thu, 09 Mar 2006 04:24:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHHOA-0006Z7-RE for sip@ietf.org; Thu, 09 Mar 2006 04:24:54 -0500 Received: from gw-eur4.philips.com ([161.85.125.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHHOA-0002XO-D7 for sip@ietf.org; Thu, 09 Mar 2006 04:24:54 -0500 Received: from smtpscan-eur4.philips.com (smtpscan-eur4.mail.philips.com [130.144.57.167]) by gw-eur4.philips.com (Postfix) with ESMTP id 2C13449728; Thu, 9 Mar 2006 09:24:53 +0000 (UTC) Received: from smtpscan-eur4.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 5D5985F; Thu, 9 Mar 2006 09:24:52 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur4.philips.com (Postfix) with ESMTP id B21C468; Thu, 9 Mar 2006 09:24:51 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id 75A5C3B; Thu, 9 Mar 2006 09:24:51 +0000 (GMT) In-Reply-To: <50B1CBA96870A34799A506B2313F2667083B49BC@ntht201e.siemenscomms.co.uk> To: "Elwell, John" Subject: Re: [Sip] Updated connected-identity draft MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Frank Derks Date: Thu, 9 Mar 2006 10:23:07 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.3FP1HF291 | September 19, 2005) at 09/03/2006 10:23:38, Serialize complete at 09/03/2006 10:23:38 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 John, I had a look at the new draft and would like to make a few comments. - In section 3 you provide an example of a transfer ("Parties involved..."). Possibly, I am missing something, but I don't see how the example relates to this draft. - It might be a good idea to move section 4 to section 9, because it relates to security aspects. - In section 5 you write about the "response identity problem". Are you referring to the fact that it is difficult to authenticate identities in responses? - The "OPEN ISSUE" in section 5, re-states something that was said earlier in the same section ("Note that it might also ..."). It would seem that this earlier statement removes the need to keep this issue open. - In 6.1/6.2/6.3 there are several occasions in which a "MUST" might be more appropriate than a "SHOULD" and a "SHOULD" than a "MAY": 6.1: "... the UPDATE method [4] SHOULD ..." -> "MUST"? "... the re-INVITE method SHOULD ..." -> "MUST"? "... the UA MAY ..." -> "SHOULD"? 6.2: "... on that dialog, the UA MAY..." -> "SHOULD"? 6.3: "... on that dialog, the UA MAY ..." -> SHOULD? - In 6.1 you raise an appropriate open issue. My two cents: for consistency's sake (see also the 4th paragraph in 6.2), I would say that this is indeed a good idea. In the same piece of text you say something about the SDP that might have to be included in the UPDATE. When this is indeed required, it also becomes necessary to say something about what this SDP has to look like. RFC3311 is not at all clear about the scope of UPDATE. UPDATE is said to be a "target refresh request", but the definition of this is rather loose: "a request that can modify the remote target of the dialog". What does "modify" mean in this context? Cheers, Frank "Elwell, John" 2006-03-06 11:50 AM To sip@ietf.org cc Subject [Sip] Updated connected-identity draft Classification draft-elwell-sip-connected-identity is now available: http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.txt Compared with the 00 version, this has changed considerably and is intended to reflect decisions made in Vancouver. It exploits the ability to change the From URI during a dialog, so that requests in the reverse direction can place the source URI in the From header field and the Identity header can be used to provide authentication, rather having to introduce new headers. Comments would be appreciated. I would like to get this adopted as a SIP WG item in Dallas. 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 06:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJ96-0001dt-8H; Thu, 09 Mar 2006 06:17:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJ95-0001QO-4N for sip@ietf.org; Thu, 09 Mar 2006 06:17:27 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHJ93-0006Ai-RC for sip@ietf.org; Thu, 09 Mar 2006 06:17:26 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IVU00501XVZUQ@siemenscomms.co.uk> for sip@ietf.org; Thu, 09 Mar 2006 11:14:27 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IVU0043WXVFPU@siemenscomms.co.uk>; Thu, 09 Mar 2006 11:14:03 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 09 Mar 2006 11:16:48 +0000 Content-return: allowed Date: Thu, 09 Mar 2006 11:16:44 +0000 From: "Elwell, John" Subject: RE: [Sip] Updated connected-identity draft To: Frank Derks Message-id: <50B1CBA96870A34799A506B2313F26670851FFF6@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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 Frank, Thanks for your comments. See my responses below. John > -----Original Message----- > From: Frank Derks [mailto:frank.derks@philips.com] > Sent: 09 March 2006 09:23 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] Updated connected-identity draft > > John, > > I had a look at the new draft and would like to make a few comments. > > - In section 3 you provide an example of a transfer ("Parties > involved..."). > Possibly, I am missing something, but I don't see how the example > relates to this draft. [JRE] On receipt of a REFER request from A, B sends an INVITE request to C. B's identity can be in the From header of the INVITE request and can be authenticated by means of an Identity header. But how does B obtain C's identity, which will not necessarily be the same as that in the To header of the INVITE request? > > - It might be a good idea to move section 4 to section 9, because it > relates to security aspects. [JRE] No, I prefer to keep the existing order, because section 4 provides much of the motivation for what follows. Section 9 covers security considerations relating to the new material in this I-D, not security considerations relating to existing capabilities. > > - In section 5 you write about the "response identity problem". Are > you referring to the fact that it is difficult to authenticate > identities in responses? [JRE] Yes, > > - The "OPEN ISSUE" in section 5, re-states something that was said > earlier in the same section ("Note that it might also ..."). It > would seem that this earlier statement removes the need to keep > this issue open. [JRE] Not really - I am not sure there is community agreement yet. > > - In 6.1/6.2/6.3 there are several occasions in which a "MUST" might > be more appropriate than a "SHOULD" and a "SHOULD" than a "MAY": > > 6.1: > "... the UPDATE method [4] SHOULD ..." -> "MUST"? [JRE] Yes, I tend to agree. > "... the re-INVITE method SHOULD ..." -> "MUST"? [JRE] Yes, I tend to agree. > "... the UA MAY ..." -> "SHOULD"? [JRE] I am not sure we should mandate indicating information to the user - that is an internal matter for the UA. Perhaps it should be "may" instead of "MAY". > > 6.2: > "... on that dialog, the UA MAY..." -> "SHOULD"? [JRE] Ditto > > 6.3: > "... on that dialog, the UA MAY ..." -> SHOULD? [JRE] Ditto > > - In 6.1 you raise an appropriate open issue. My two cents: for > consistency's sake (see also the 4th paragraph in 6.2), I would > say that this is indeed a good idea. [JRE] Yes, comments to date seem to support this. > > In the same piece of text you say something about the SDP that > might have to be included in the UPDATE. When this is indeed > required, it also becomes necessary to say something about what > this SDP has to look like. RFC3311 is not at all clear about > the scope of UPDATE. UPDATE is said to be a "target refresh > request", but the definition of this is rather loose: "a > request that can modify the remote target of the dialog". What > does "modify" mean in this context? [JRE] It means change the Contact URI. > > Cheers, > > Frank > > > > > > > > > "Elwell, John" > 2006-03-06 11:50 AM > > To > sip@ietf.org > cc > > Subject > [Sip] Updated connected-identity draft > Classification > > > > > > > > draft-elwell-sip-connected-identity is now available: > http://www.ietf.org/internet-drafts/draft-elwell-sip-connected > -identity-01.txt > > Compared with the 00 version, this has changed considerably and is > intended to reflect decisions made in Vancouver. It exploits > the ability > to change the From URI during a dialog, so that requests in > the reverse > direction can place the source URI in the From header field and the > Identity header can be used to provide authentication, rather > having to > introduce new headers. Comments would be appreciated. I would > like to get > this adopted as a SIP WG item in Dallas. > 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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 08:25:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHL7b-0006IR-35; Thu, 09 Mar 2006 08:24:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHL7Z-0006I1-Od for sip@ietf.org; Thu, 09 Mar 2006 08:24:01 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHL7Y-0001Mu-8V for sip@ietf.org; Thu, 09 Mar 2006 08:24:01 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id k29DNx7i175800 for ; Thu, 9 Mar 2006 13:23:59 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k29DOLxe203514 for ; Thu, 9 Mar 2006 14:24:21 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k29DNwgs022867 for ; Thu, 9 Mar 2006 14:23:58 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k29DNwQV022864 for ; Thu, 9 Mar 2006 14:23:58 +0100 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Thu, 9 Mar 2006 15:24:20 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 09/03/2006 15:24:20, Serialize complete at 09/03/2006 15:24:20 X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Sip] Case sensitivity of user name - why RFC 3261 is more strict then RFC 2543 X-BeenThere: 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="===============0357970629==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0357970629== Content-Type: multipart/alternative; boundary="=_alternative 00497D15C225712C_=" This is a multipart message in MIME format. --=_alternative 00497D15C225712C_= Content-Type: text/plain; charset="US-ASCII" RFC 2543 (section 2, page 24) allows for: SIP URLs are case-insensitive, so that for example the two URLs sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All URL parameters are included when comparing SIP URLs for equality. That is RFC 2543 does not care about the case of the user name. RFC 3261 says in section 19.14: SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) sip:alice@AtLanTa.CoM;Transport=UDP That is we are having a stricter rules for user name comparison. Does anyone remember why it was done? I could not find a reference to this in the list of changes from RFC 2543 at the end of RFC 3261. In email as far as I know user names are NOT case sensitive. RFC 821 only says: Commands and replies are not case sensitive. That is, a command or reply word may be upper case, lower case, or any mixture of upper and lower case. Note that this is not true of mailbox user names. For some hosts the user name is case sensitive, and SMTP implementations must take case to preserve the case of user names as they appear in mailbox arguments. Host names are not case sensitive. So for email servers need only to preserve the name casing. --Avshalom --=_alternative 00497D15C225712C_= Content-Type: text/html; charset="US-ASCII"
RFC 2543 (section 2, page 24) allows for:

   SIP URLs are case-insensitive, so that for example the two URLs
   sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent.  All
   URL parameters are included when comparing SIP URLs for equality.

That is RFC 2543 does not care about the case of the user name.

RFC 3261 says in section 19.14:

   SIP:ALICE@AtLanTa.CoM;Transport=udp             (different usernames)
   sip:alice@AtLanTa.CoM;Transport=UDP

That is we are having a stricter rules for user name comparison.

Does anyone remember why it was done? I could not find a reference to this in
the list of changes from RFC 2543 at the end of RFC 3261.

In email as far as I know user names are NOT case sensitive. RFC 821 only says:

   Commands and replies are not case sensitive.  That is, a command or
   reply word may be upper case, lower case, or any mixture of upper and
   lower case.  Note that this is not true of mailbox user names.  For
   some hosts the user name is case sensitive, and SMTP implementations
   must take case to preserve the case of user names as they appear in
   mailbox arguments.  Host names are not case sensitive.

So for email servers need only to preserve the name casing.

--Avshalom
 --=_alternative 00497D15C225712C_=-- --===============0357970629== 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 --===============0357970629==-- From sip-bounces@ietf.org Thu Mar 09 09:29:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHM6w-0002Ws-A1; Thu, 09 Mar 2006 09:27:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHM6u-0002Wk-51 for sip@ietf.org; Thu, 09 Mar 2006 09:27:24 -0500 Received: from nproxy.gmail.com ([64.233.182.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHM6r-0003hS-3D for sip@ietf.org; Thu, 09 Mar 2006 09:27:24 -0500 Received: by nproxy.gmail.com with SMTP id l23so170378nfc for ; Thu, 09 Mar 2006 06:27:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=cDZD6ZsEkzJ/3FRxwRiGG0ht/o7tVzCOdRVIvmwQiTOLz4DgO4MjEoF1P502PFTmO9IK55sbcicqBnwyTY83pNNjUHx1ExLmY97WK8Ok8pUHihhNDhZMpHGtkgwlEB0RcA0LWjhF6hCP3hbNE2juP+gwf4ItK396rrX+rr/O9Ik= Received: by 10.49.94.20 with SMTP id w20mr508393nfl; Thu, 09 Mar 2006 06:27:19 -0800 (PST) Received: by 10.48.210.10 with HTTP; Thu, 9 Mar 2006 06:27:19 -0800 (PST) Message-ID: <469e87290603090627o6c2734b6p8b1088332d19781f@mail.gmail.com> Date: Thu, 9 Mar 2006 19:57:19 +0530 From: "Prince A P" To: sip@ietf.org Subject: Re: RE: [Sip] The Problem with PRACK In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98 X-BeenThere: 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="===============0374364213==" Errors-To: sip-bounces@ietf.org --===============0374364213== Content-Type: multipart/alternative; boundary="----=_Part_7984_3783594.1141914439778" ------=_Part_7984_3783594.1141914439778 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, If the 3262 is only for Reliability of Provisional responses, Why should it mandate Offer-Answer completion? Was there any rationale behind clubbing Reliability with Offer-Answer? rgds, Prince > To: "Samir Srivastava" , "Paul Kyzivat" < > pkyzivat@cisco.com>, "Francois Audet" > From: "Samir Srivastava" > Date: 03/09/2006 01:18PM > cc: IETF SIP List > Subject: RE: [Sip] The Problem with PRACK > > We can do it, by adding more logic / header. UAS knows about all the > hops by complete via header set inspection. When sending 1xx, it need to > indicate in this new header to be defined. Is it worth > defining this ? > > > Thx > Samir > > -----Original Message----- > From: Srivastava, Samir [SC100:8826:EXCH] > Sent: Wednesday, March 08, 2006 11:19 PM > To: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH] > Cc: IETF SIP List > Subject: RE: [Sip] The Problem with PRACK > > We can do for SIPS only. > > Thx > Samir > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com ] > Sent: Wednesday, March 08, 2006 7:29 PM > To: Audet, Francois [SC100:3055:EXCH] > Cc: IETF SIP List > Subject: Re: [Sip] The Problem with PRACK > > > > Francois Audet wrote: > > I'm ok with the suggestion to deprecate using PRACK for Offer/Answer. > > > > While we are at it, why not go for deprecating the use PRACK > > altogether when TCP transport is used? > > Explain to me again how you would know that reliable transport is used > end to end? > > Paul > > > On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: > > > >> Hi, > >> > >> A things about PRACK come immediately to mind that are a pain to > >> implement: > >> > >> 1) The UAS has to queue provisionals until it receives a PRACK for > >> the first provisional. This is due to RSeq starting at an arbitrary > >> value instead of just starting at 1. This is probably the simplest > >> to fix, by just requiring the UAC to always start with a RSeq of 1. > >> > >> 2) Multiple unacknowledged provisionals can be in flight at the same > >> time. We could potentially eliminate this requirement by > >> acknowledging the current status instead of the whole history. In > >> other words, when the UAS sends a new reliable provisional, it > >> decides which (if any) of the previously sent provisionals are still > >> relevant and sends all of them (as sipfrags or something) as a single > > >> reliable request. > >> > >> 3) If you "answer" and want to deliver a 200 OK, you have to queue it > > >> and wait if you are waiting for a PRACK to an offer or answer. > >> Keeping track of when you can send the 200 would be easier if we did > >> something like I recommend in #2. > >> > >> 4) Even for an acknowledged provisional, you still have to retransmit > > >> approximately every minute (I forget exactly) to prevent old proxies > >> from deleting state for your transaction. This is one of those minor > > >> annoyances that is *almost* operationally irrelevant, and unlikely to > > >> not get coded. My proposal for simplification is to retransmit the > >> latest reliable provisional in exactly the same way that the UAS > >> retransmits unreliable provisionals. Who cares if there is an extra > >> message or two for a call with 1 minute + post-answer delay? > >> > >> 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I > >> talked Jonathan into this, and I've been sorry I did ever since. My > >> apologies to everyone for making a bad decision. > >> > >> Hope this helps. > >> thanks, > >> -rohan > >> > >> On 3/7/06, *Jonathan Rosenberg* >> >> wrote: > >> > >> At the last IETF, there was a lot of discussion and argument > around > >> PRACK. The spark of this debate was the ICE specification, which > had > >> words in it requiring the usage of PRACK and UPDATE in order to > work > >> with early media. There was strong pushback from many > implementors > >> that > >> anything requiring PRACK is unacceptable. Rohan put up a slide > (IIRC) > >> that showed the state machine in his implementation resulting > from > >> PRACK, and it was not pretty. > >> > >> So, I'd like to discuss exactly what IS the problem with PRACK? > There > >> are really two pieces of state machinery in play here. One piece > >> is the > >> complication that PRACK introduces into the offer/answer model. > With > >> PRACK, you can now get a final answer in the 18x, and then send a > new > >> offer in UPDATE, or even in PRACK itself. Another piece is the > state > >> machinery with the retransmissions itself - correlating the PRACK > >> with a > >> particular reliable provisional response and causing it to stop. > >> > >> In a chat with Flemming today, he suggested in interested remedy > >> to our > >> PRACK dilemma. Why not revise PRACK so that you can't send an > offer or > >> answer with it; it has no impact on the set of allowed O/A > exchanges > >> defined by RFC 3261. I'm not sure if that would consequently > break the > >> preconditions mechanism, but maybe there are some kind of > offer/answer > >> limitations that would simplify things. > >> > >> So, this is one idea. I'd like for people who have complained > about > >> PRACK implementations to speak up and indicate what exactly makes > >> it so > >> complicated for them. > >> > >> 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 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > > ------=_Part_7984_3783594.1141914439778 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
 
If the 3262 is only for Reliability of Provisional responses, Why shou= ld
it mandate Offer-Answer completion?
 
Was there any rationale behind clubbing Reliability with Offer-Answer?=
 
rgds,
Prince


 
To: "Samir Sriva= stava" < samirsr@nortel.com>, "Paul Kyzivat" <pkyzivat@cisco.com>, "Francois Audet" = < audet@nortel.com>
From: "= ;Samir Srivastava" < samirsr@nortel.com>
Date: 03/09/2006 01:18PM
cc: IETF SIP List= <sip@ietf.org>
Subject: RE: [= Sip] The Problem with PRACK

We can do it, by adding more logic / header. UAS knows about all the=
hops by complete via header set inspection. When sending 1xx, it need t= o
indicate in this new header to be defined. Is it worth
defining this= ?


Thx
Samir

-----Original Message-----
From: Sriva= stava, Samir [SC100:8826:EXCH]
Sent: Wednesday, March 08, 2006 11:19 PM
To: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH]
Cc: IETF SIP Lis= t
Subject: RE: [Sip] The Problem with PRACK

We can do for SIPS on= ly.

Thx
Samir

-----Original Message-----
From: Paul Ky= zivat [ mailto:pkyzivat@cisco.com]
Sen= t: Wednesday, March 08, 2006 7:29 PM
To: Audet, Francois [SC100:3055:EXC= H]
Cc: IETF SIP List
Subject: Re: [Sip] The Problem with PRACK

<= br>
Francois Audet wrote:
> I'm ok with the suggestion to deprecat= e using PRACK for Offer/Answer.
>
> While we are at it, why n= ot go for deprecating the use PRACK=20
> altogether when TCP transport is used?

Explain to me again = how you would know that reliable transport is used
end to end?

    Paul

> On Mar 8, 2006, at 15:5= 1 , Rohan Mahy wrote:
>
>> Hi,
>>
>> A things about PRACK come= immediately to mind that are a pain to
>> implement:
>><= br>>> 1) The UAS has to queue provisionals until it receives a PRACK = for=20
>> the first provisional.  This is due to RSeq starting at a= n arbitrary
>> value instead of just starting at 1.  This is= probably the simplest
>> to fix, by just requiring the UAC to al= ways start with a RSeq of 1.
>>
>> 2) Multiple unacknowledged provisionals can be in = flight at the same
>> time.  We could potentially eliminate = this requirement by
>> acknowledging the current status instead o= f the whole history.  In=20
>> other words, when the UAS sends a new reliable provisional, it=
>> decides which (if any) of the previously sent provisionals ar= e still
>> relevant and sends all of them (as sipfrags or somethi= ng) as a single

>> reliable request.
>>
>> 3) If you "= answer" and want to deliver a 200 OK, you have to queue it

>= > and wait if you are waiting for a PRACK to an offer or answer.
>> Keeping track of when you can send the 200 would be easier if we d= id
>> something like I recommend in #2.
>>
>> 4= ) Even for an acknowledged provisional, you still have to retransmit

>> approximately every minute (I forget exactly) to prevent old p= roxies
>> from deleting state for your transaction.  This is= one of those minor

>> annoyances that is *almost* operational= ly irrelevant, and unlikely to

>> not get coded.  My proposal for simplification is to = retransmit the
>> latest reliable provisional in exactly the same= way that the UAS
>> retransmits unreliable provisionals.  W= ho cares if there is an extra=20
>> message or two for a call with 1 minute + post-answer delay?>>
>> 5) I would deprecate the PRACK/200 (PRACK) offer/ans= wer exchange.  I
>> talked Jonathan into this, and I've been= sorry I did ever since.  My=20
>> apologies to everyone for making a bad decision.
>>>> Hope this helps.
>> thanks,
>> -rohan
>&= gt;
>> On 3/7/06, *Jonathan Rosenberg* < jdrosen@cisco.com
>> <mailto:jdrosen@cisco.com>> wrote:
>>
>>  =   At the last IETF, there was a lot of discussion and argument
around
>>     PRACK. The spark of this debate was th= e ICE specification, which
had
>>     words in it req= uiring the usage of PRACK and UPDATE in order to
work
>>  =   with early media. There was strong pushback from many
implementors
>>     that
>>     a= nything requiring PRACK is unacceptable. Rohan put up a slide
(IIRC)
= >>     that showed the state machine in his implementation = resulting
from
>>     PRACK, and it was not pretty.
>>
>>     So, I'd like to discuss exactly what= IS the problem with PRACK?
There
>>     are really t= wo pieces of state machinery in play here. One piece
>>   &nb= sp; is the
>>     complication that PRACK introduces int= o the offer/answer model.
With
>>     PRACK, you can now get a final answer in= the 18x, and then send a
new
>>     offer in UPDATE,= or even in PRACK itself. Another piece is the
state
>>   =   machinery with the retransmissions itself - correlating the PRACK
>>     with a
>>     particular reli= able provisional response and causing it to stop.
>>
>> &= nbsp;   In a chat with Flemming today, he suggested in interested reme= dy
>>     to our
>>     PRACK dilemma. Why not revise PRACK so that you can'= t send an
offer or
>>     answer with it; it has no i= mpact on the set of allowed O/A
exchanges
>>     defi= ned by RFC 3261. I'm not sure if that would consequently
break the
>>     preconditions mechanism, but maybe = there are some kind of
offer/answer
>>     limitation= s that would simplify things.
>>
>>     So, thi= s is one idea. I'd like for people who have complained
about
>>     PRACK implementations to speak up and i= ndicate what exactly makes
>>     it so
>> &nbs= p;   complicated for them.
>>
>>     Thank= s,
>>     Jonathan R.
>>     --
>>     Jonathan D. Rosenberg, Ph.D.      = ;             600 Lanidex Plaza
>> &= nbsp;   Cisco Fellow               =                     Parsi= ppany, NJ
>>     07054-2711
>>     Ci= sco Systems
>>    =20 jdrosen@cisco.com
>> &nbs= p;   < mailto:jdrosen@cisco.com>             =                  FAX:  >>     (973) 952-5050
>>     http://www.jdrosen.net              =           PHONE: (973)
952-5000
>> &nb= sp;   http://www.cisco.com
>>
>>     ________________________________________= _______
>>     Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
>>     &l= t;https://www1.ietf.= org/mailman/listinfo/sip >
>>     This list is for NEW development of the = core SIP Protocol
>>     Use sip-implementors@cs.columbia.edu
>>     <mailto:sip-implementors@cs.colu= mbia.edu > for questions on
current sip
>>     Use sipping@ietf.org < mailto:sipping@ietf.org> for new
>>     developme= nts on the application of sip
>>
>>
>> _________= ______________________________________
>> Sip mailing list  <= a onclick=3D"return top.js.OpenExtLink(window,event,this)" href=3D"https://= www1.ietf.org/mailman/listinfo/sip" target=3D"_blank"> https://www1.ietf.org/mailman/listinfo/sip
>> This list is for= NEW development of the core SIP Protocol Use
>> sip-implementors@cs.columbia.edu
>> <mailto:sip-implementors@cs.columbia.edu&= gt; for questions on current=20
>> sip Use sipping@ietf.org < mailto:sipping@ietf.org> for new
>> developments on the ap= plication of sip
>
>
>
> -----------------------= -----------------------------------------------
> --
>
> _______________________________________________
> Sip mailing li= st  https://w= ww1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use =
> sip-implemen= tors@cs.columbia.edu for questions on current sip Use
> sipping@ietf.org for new developments on the application of sip=

_______________________________________________
Sip mailing list &nb= sp;https://www1.ietf= .org/mailman/listinfo/sip
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

_______________________________________________
Sip mailing list &nb= sp;https://www1.ietf= .org/mailman/listinfo/sip
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

_______________________________________________
Sip mailing list &nb= sp;https://www1.ietf= .org/mailman/listinfo/sip
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


 

------=_Part_7984_3783594.1141914439778-- --===============0374364213== 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 --===============0374364213==-- From sip-bounces@ietf.org Thu Mar 09 11:21:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNrI-0001lH-MS; Thu, 09 Mar 2006 11:19:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNrG-0001cy-JQ for sip@ietf.org; Thu, 09 Mar 2006 11:19:22 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNrF-0007Gx-9G for sip@ietf.org; Thu, 09 Mar 2006 11:19:22 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k29GJKXh011453; Thu, 9 Mar 2006 10:19:20 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k29GJJv20827; Thu, 9 Mar 2006 10:19:19 -0600 (CST) Message-ID: <44105587.1030908@lucent.com> Date: Thu, 09 Mar 2006 10:19:19 -0600 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] I-D ACTION:draft-ietf-sip-connect-reuse-05.txt References: <03da01c642ef$83391110$31713b51@BEMBUSTER> In-Reply-To: <03da01c642ef$83391110$31713b51@BEMBUSTER> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 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="===============1274751173==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1274751173== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000607020301070700030007" This is a cryptographically signed message in MIME format. --------------ms000607020301070700030007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeroen van Bemmel wrote: > Hi, > > A suggestion: Instead of installing the alias at the time a request with > a top Via containing 'alias' is received, what about doing it the moment > a 101-2xx response is forwarded back upstream? I believe that could be an implementation detail, but as far as I can tell, this is simply delaying the alias binding. And I am not quite sure how this delay alleviates the security attacks since these attacks are launched from the sender's host. > Also, for security reasons perhaps the types of requests that may carry > an alias should be restricted. For example, a CANCEL may not be > challenged, so it would not be wise to allow it to establish an alias. > Same for ACK, and what about OPTIONS? But a CANCEL or ACK sent over TLS will still go through the normal cert authentication, so at least over TLS I don't see why CANCEL and ACK ought to be restricted. The question of whether the receiving end should establish an alias for OPTIONS or MESSAGE is fair. I think it should be okay for TLS transports, but would like to hear what others think. Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms000607020301070700030007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMDkxNjE5MTlaMCMGCSqGSIb3DQEJ BDEWBBSjexRGwD2Uj1rJiBiXv1Bl2x/utzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAqcL4wrJUdssEQnKzTTtPFAfoxrX7a9Aw3hFS/abVwQU7P08HuYIU vAZTvWUMLrNdL24FKXh6CYXFxaroCUAMi9UNPjmn+IJyVL6SH/K7Mso3E0Ok2EycirVZQSae y3gwGNHnkS+d9VilsoVFr5WkMnH5QwzT2bBpQAogJlvwg8YAAAAAAAA= --------------ms000607020301070700030007-- --===============1274751173== 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 --===============1274751173==-- From sip-bounces@ietf.org Thu Mar 09 11:30:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHO0L-0001ri-Jn; Thu, 09 Mar 2006 11:28:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHO0K-0001rd-LF for sip@ietf.org; Thu, 09 Mar 2006 11:28:44 -0500 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 1FHO0J-0007Y8-T6 for sip@ietf.org; Thu, 09 Mar 2006 11:28:44 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2006 08:28:43 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k29GSgw3005695; Thu, 9 Mar 2006 08:28:43 -0800 (PST) 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.211); Thu, 9 Mar 2006 11:28:42 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 11:28:41 -0500 Message-ID: <441057B9.8010602@cisco.com> Date: Thu, 09 Mar 2006 11:28:41 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Prince A P Subject: Re: [Sip] The Problem with PRACK References: <469e87290603090627o6c2734b6p8b1088332d19781f@mail.gmail.com> In-Reply-To: <469e87290603090627o6c2734b6p8b1088332d19781f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 16:28:41.0869 (UTC) FILETIME=[872D5BD0:01C64396] X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae 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 Prince A P wrote: > Hi, > > If the 3262 is only for Reliability of Provisional responses, Why should > it mandate Offer-Answer completion? > Was there any rationale behind clubbing Reliability with Offer-Answer? I wasn't there when that was done, so I can't speak to the actual motives of those who were. But note that offer/answer has no mechanism of its own - it must be associated with some messages in the signaling system. Reliable provisionals, without sdp in the PRACK, are sufficient for early completion of the offer/answer exchange when the offer is in the invite. But that isn't sufficient to achieve early completion of offer/answer when there is no offer in the invite. In that case the offer is in the reliable provisional, and the obvious place for the answer is in the PRACK. That seems to be reasonable justification for involving PRACK in offer/answer. Allowing an offer in PRACK is less motivated. Essentially the same thing can be done using UPDATE. I can speculate on some reasons for allowing PRACK to be used for this: - done before UPDATE was invented - efficiency - the prack is required anyway - prack already needs to carry an answer, why not an offer Paul > > rgds, > Prince > > > > > To: "Samir Srivastava" < samirsr@nortel.com > >, "Paul Kyzivat" >, "Francois Audet" < > audet@nortel.com > > From: "Samir Srivastava" < samirsr@nortel.com > > > Date: 03/09/2006 01:18PM > cc: IETF SIP List > > Subject: RE: [Sip] The Problem with PRACK > > We can do it, by adding more logic / header. UAS knows about all the > hops by complete via header set inspection. When sending 1xx, it > need to > indicate in this new header to be defined. Is it worth > defining this ? > > > Thx > Samir > > -----Original Message----- > From: Srivastava, Samir [SC100:8826:EXCH] > Sent: Wednesday, March 08, 2006 11:19 PM > To: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH] > Cc: IETF SIP List > Subject: RE: [Sip] The Problem with PRACK > > We can do for SIPS only. > > Thx > Samir > > -----Original Message----- > From: Paul Kyzivat [ mailto:pkyzivat@cisco.com] > Sent: Wednesday, March 08, 2006 7:29 PM > To: Audet, Francois [SC100:3055:EXCH] > Cc: IETF SIP List > Subject: Re: [Sip] The Problem with PRACK > > > > Francois Audet wrote: > > I'm ok with the suggestion to deprecate using PRACK for > Offer/Answer. > > > > While we are at it, why not go for deprecating the use PRACK > > altogether when TCP transport is used? > > Explain to me again how you would know that reliable transport > is used > end to end? > > Paul > > > On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: > > > >> Hi, > >> > >> A things about PRACK come immediately to mind that are a pain to > >> implement: > >> > >> 1) The UAS has to queue provisionals until it receives a > PRACK for > >> the first provisional. This is due to RSeq starting at an > arbitrary > >> value instead of just starting at 1. This is probably the > simplest > >> to fix, by just requiring the UAC to always start with a > RSeq of 1. > >> > >> 2) Multiple unacknowledged provisionals can be in flight at > the same > >> time. We could potentially eliminate this requirement by > >> acknowledging the current status instead of the whole > history. In > >> other words, when the UAS sends a new reliable provisional, it > >> decides which (if any) of the previously sent provisionals > are still > >> relevant and sends all of them (as sipfrags or something) as > a single > > >> reliable request. > >> > >> 3) If you "answer" and want to deliver a 200 OK, you have to > queue it > > >> and wait if you are waiting for a PRACK to an offer or answer. > >> Keeping track of when you can send the 200 would be easier > if we did > >> something like I recommend in #2. > >> > >> 4) Even for an acknowledged provisional, you still have to > retransmit > > >> approximately every minute (I forget exactly) to prevent old > proxies > >> from deleting state for your transaction. This is one of > those minor > > >> annoyances that is *almost* operationally irrelevant, and > unlikely to > > >> not get coded. My proposal for simplification is to > retransmit the > >> latest reliable provisional in exactly the same way that the > UAS > >> retransmits unreliable provisionals. Who cares if there is > an extra > >> message or two for a call with 1 minute + post-answer delay? > >> > >> 5) I would deprecate the PRACK/200 (PRACK) offer/answer > exchange. I > >> talked Jonathan into this, and I've been sorry I did ever > since. My > >> apologies to everyone for making a bad decision. > >> > >> Hope this helps. > >> thanks, > >> -rohan > >> > >> On 3/7/06, *Jonathan Rosenberg* < jdrosen@cisco.com > > >> > wrote: > >> > >> At the last IETF, there was a lot of discussion and > argument > around > >> PRACK. The spark of this debate was the ICE > specification, which > had > >> words in it requiring the usage of PRACK and UPDATE in > order to > work > >> with early media. There was strong pushback from many > implementors > >> that > >> anything requiring PRACK is unacceptable. Rohan put up a > slide > (IIRC) > >> that showed the state machine in his implementation > resulting > from > >> PRACK, and it was not pretty. > >> > >> So, I'd like to discuss exactly what IS the problem with > PRACK? > There > >> are really two pieces of state machinery in play here. > One piece > >> is the > >> complication that PRACK introduces into the offer/answer > model. > With > >> PRACK, you can now get a final answer in the 18x, and > then send a > new > >> offer in UPDATE, or even in PRACK itself. Another piece > is the > state > >> machinery with the retransmissions itself - correlating > the PRACK > >> with a > >> particular reliable provisional response and causing it > to stop. > >> > >> In a chat with Flemming today, he suggested in > interested remedy > >> to our > >> PRACK dilemma. Why not revise PRACK so that you can't > send an > offer or > >> answer with it; it has no impact on the set of allowed O/A > exchanges > >> defined by RFC 3261. I'm not sure if that would > consequently > break the > >> preconditions mechanism, but maybe there are some kind of > offer/answer > >> limitations that would simplify things. > >> > >> So, this is one idea. I'd like for people who have > complained > about > >> PRACK implementations to speak up and indicate what > exactly makes > >> it so > >> complicated for them. > >> > >> Thanks, > >> Jonathan R. > >> -- > >> Jonathan D. Rosenberg, Ph.D. 600 > Lanidex Plaza > >> Cisco Fellow > Parsippany, NJ > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com > >> < mailto: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 < > mailto:sipping@ietf.org> for new > >> developments on the application of sip > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use > >> sip-implementors@cs.columbia.edu > > >> for questions on > current > >> sip Use sipping@ietf.org < > mailto:sipping@ietf.org> for new > >> developments on the application of sip > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu > for questions on > current sip Use > > sipping@ietf.org for new > developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu > for questions on > current sip Use > sipping@ietf.org for new developments > on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu > for questions on > current sip > Use sipping@ietf.org for new > developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu > for questions on > current sip > Use sipping@ietf.org for new > developments on the application of sip > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 13:25:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHPnG-0006ow-Em; Thu, 09 Mar 2006 13:23:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHPnF-0006or-ET for sip@ietf.org; Thu, 09 Mar 2006 13:23:21 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHPnE-0002jd-0b for sip@ietf.org; Thu, 09 Mar 2006 13:23:21 -0500 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 k29INFl13446; Thu, 9 Mar 2006 13:23:16 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Thu, 9 Mar 2006 12:22:58 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF077D0271@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDKalJV468SYxlSFKcLyuaY5twhAAe+LZg From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 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 wouldn't. You would follow the RFC 3261 rule, i.e., you send the Answer in the 200 (and you MAY also include it in the 18X). That's already how it works. I guess what you are worried about is the case where a proxy unilateraly decides to downgrade from TCP to UDP. While I really don't see any rationale for proxies to do such a thing, it is certainly possible. But that would still be RFC 3261 compliant. The theoretical risk is loosing some in-band media until the next 18x or the 200 arrives. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, March 08, 2006 19:29 > To: Audet, Francois [SC100:3055:EXCH] > Cc: Rohan Mahy; IETF SIP List > Subject: Re: [Sip] The Problem with PRACK >=20 >=20 >=20 >=20 > Francois Audet wrote: > > I'm ok with the suggestion to deprecate using PRACK for=20 > Offer/Answer. > >=20 > > While we are at it, why not go for deprecating the use PRACK=20 > > altogether > > when TCP transport is used? >=20 > Explain to me again how you would know that reliable=20 > transport is used=20 > end to end? >=20 > Paul >=20 > > On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: > >=20 > >> Hi, > >> > >> A things about PRACK come immediately to mind that are a pain to > >> implement: > >> > >> 1) The UAS has to queue provisionals until it receives a PRACK for=20 > >> the > >> first provisional. This is due to RSeq starting at an=20 > arbitrary value=20 > >> instead of just starting at 1. This is probably the=20 > simplest to fix,=20 > >> by just requiring the UAC to always start with a RSeq of 1. > >> > >> 2) Multiple unacknowledged provisionals can be in flight=20 > at the same > >> time. We could potentially eliminate this requirement by=20 > >> acknowledging the current status instead of the whole history. In=20 > >> other words, when the UAS sends a new reliable=20 > provisional, it decides=20 > >> which (if any) of the previously sent provisionals are=20 > still relevant=20 > >> and sends all of them (as sipfrags or something) as a=20 > single reliable=20 > >> request. > >> > >> 3) If you "answer" and want to deliver a 200 OK, you have=20 > to queue it > >> and wait if you are waiting for a PRACK to an offer or=20 > answer. Keeping=20 > >> track of when you can send the 200 would be easier if we=20 > did something=20 > >> like I recommend in #2.=20 > >> > >> 4) Even for an acknowledged provisional, you still have to=20 > retransmit > >> approximately every minute (I forget exactly) to prevent=20 > old proxies=20 > >> from deleting state for your transaction. This is one of=20 > those minor=20 > >> annoyances that is *almost* operationally irrelevant, and=20 > unlikely to=20 > >> not get coded. My proposal for simplification is to=20 > retransmit the=20 > >> latest reliable provisional in exactly the same way that the UAS=20 > >> retransmits unreliable provisionals. Who cares if there=20 > is an extra=20 > >> message or two for a call with 1 minute + post-answer delay? > >> > >> 5) I would deprecate the PRACK/200 (PRACK) offer/answer=20 > exchange. I > >> talked Jonathan into this, and I've been sorry I did ever=20 > since. My=20 > >> apologies to everyone for making a bad decision. > >> > >> Hope this helps. > >> thanks, > >> -rohan > >> > >> On 3/7/06, *Jonathan Rosenberg* >> > wrote: > >> > >> At the last IETF, there was a lot of discussion and=20 > argument around > >> PRACK. The spark of this debate was the ICE=20 > specification, which had > >> words in it requiring the usage of PRACK and UPDATE in=20 > order to work > >> with early media. There was strong pushback from many=20 > implementors > >> that > >> anything requiring PRACK is unacceptable. Rohan put up=20 > a slide (IIRC) > >> that showed the state machine in his implementation=20 > resulting from > >> PRACK, and it was not pretty. > >> > >> So, I'd like to discuss exactly what IS the problem=20 > with PRACK? There > >> are really two pieces of state machinery in play here.=20 > One piece > >> is the > >> complication that PRACK introduces into the=20 > offer/answer model. With > >> PRACK, you can now get a final answer in the 18x, and=20 > then send a new > >> offer in UPDATE, or even in PRACK itself. Another=20 > piece is the state > >> machinery with the retransmissions itself -=20 > correlating the PRACK > >> with a > >> particular reliable provisional response and causing=20 > it to stop. > >> > >> In a chat with Flemming today, he suggested in=20 > interested remedy > >> to our > >> PRACK dilemma. Why not revise PRACK so that you can't=20 > send an offer or > >> answer with it; it has no impact on the set of allowed=20 > O/A exchanges > >> defined by RFC 3261. I'm not sure if that would=20 > consequently break the > >> preconditions mechanism, but maybe there are some kind=20 > of offer/answer > >> limitations that would simplify things. > >> > >> So, this is one idea. I'd like for people who have=20 > complained about > >> PRACK implementations to speak up and indicate what=20 > exactly makes > >> it so > >> complicated for them. > >> > >> Thanks, > >> Jonathan R. > >> -- > >> Jonathan D. Rosenberg, Ph.D. 600=20 > Lanidex Plaza > >> Cisco Fellow 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 > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu > >> for=20 > questions on current sip > >> Use sipping@ietf.org for new > >> developments on the application 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=20 > >> for questions on current=20 > >> sip Use sipping@ietf.org for new=20 > >> 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 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 13:55:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQGN-0007sr-TI; Thu, 09 Mar 2006 13:53:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQGM-0007sm-Kh for sip@ietf.org; Thu, 09 Mar 2006 13:53:26 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHQGL-0003ic-5O for sip@ietf.org; Thu, 09 Mar 2006 13:53:26 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Mar 2006 10:53:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,179,1139212800"; d="scan'208"; a="23293615:sNHT27780188" 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 k29IrOWc027146; Thu, 9 Mar 2006 13:53:24 -0500 (EST) 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.211); Thu, 9 Mar 2006 13:53:24 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 13:53:23 -0500 Message-ID: <441079A3.3040906@cisco.com> Date: Thu, 09 Mar 2006 13:53:23 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] The Problem with PRACK References: <1ECE0EB50388174790F9694F77522CCF077D0271@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF077D0271@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 18:53:23.0893 (UTC) FILETIME=[BE111650:01C643AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 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: > You wouldn't. > > You would follow the RFC 3261 rule, i.e., you send the Answer in the > 200 (and you MAY also include it in the 18X). That's already how it > works. > > I guess what you are worried about is the case where a proxy unilateraly > decides to downgrade from TCP to UDP. While I really don't see any > rationale > for proxies to do such a thing, it is certainly possible. But that would > still be RFC 3261 compliant. The theoretical risk is loosing some > in-band > media until the next 18x or the 200 arrives. I am still not following what you are suggesting. You say "deprecating the use PRACK altogether when TCP transport is used". Does that mean the UAC omits Supported:100rel if it is using TCP? Or that the UAS refuses 100rel when it receives a request over TCP? Or that 100rel is supported but still the UAS doesn't use PRACK? Its clearly possible that the access link for the UAC is TCP while that of the UAS is UDP, or visa versa. Assuming that the e2e path is reliable without prack seems like a really bad idea. And losing in band media can be a bad thing, such as when it is telling you why your call didn't get where it was intended to go. This can easily happen without there ever being a 200. Paul >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Wednesday, March 08, 2006 19:29 >>To: Audet, Francois [SC100:3055:EXCH] >>Cc: Rohan Mahy; IETF SIP List >>Subject: Re: [Sip] The Problem with PRACK >> >> >> >> >>Francois Audet wrote: >> >>>I'm ok with the suggestion to deprecate using PRACK for >> >>Offer/Answer. >> >>>While we are at it, why not go for deprecating the use PRACK >>>altogether >>>when TCP transport is used? >> >>Explain to me again how you would know that reliable >>transport is used >>end to end? >> >> Paul >> >> >>>On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: >>> >>> >>>>Hi, >>>> >>>>A things about PRACK come immediately to mind that are a pain to >>>>implement: >>>> >>>>1) The UAS has to queue provisionals until it receives a PRACK for >>>>the >>>>first provisional. This is due to RSeq starting at an >> >>arbitrary value >> >>>>instead of just starting at 1. This is probably the >> >>simplest to fix, >> >>>>by just requiring the UAC to always start with a RSeq of 1. >>>> >>>>2) Multiple unacknowledged provisionals can be in flight >> >>at the same >> >>>>time. We could potentially eliminate this requirement by >>>>acknowledging the current status instead of the whole history. In >>>>other words, when the UAS sends a new reliable >> >>provisional, it decides >> >>>>which (if any) of the previously sent provisionals are >> >>still relevant >> >>>>and sends all of them (as sipfrags or something) as a >> >>single reliable >> >>>>request. >>>> >>>>3) If you "answer" and want to deliver a 200 OK, you have >> >>to queue it >> >>>>and wait if you are waiting for a PRACK to an offer or >> >>answer. Keeping >> >>>>track of when you can send the 200 would be easier if we >> >>did something >> >>>>like I recommend in #2. >>>> >>>>4) Even for an acknowledged provisional, you still have to >> >>retransmit >> >>>>approximately every minute (I forget exactly) to prevent >> >>old proxies >> >>>>from deleting state for your transaction. This is one of >> >>those minor >> >>>>annoyances that is *almost* operationally irrelevant, and >> >>unlikely to >> >>>>not get coded. My proposal for simplification is to >> >>retransmit the >> >>>>latest reliable provisional in exactly the same way that the UAS >>>>retransmits unreliable provisionals. Who cares if there >> >>is an extra >> >>>>message or two for a call with 1 minute + post-answer delay? >>>> >>>>5) I would deprecate the PRACK/200 (PRACK) offer/answer >> >>exchange. I >> >>>>talked Jonathan into this, and I've been sorry I did ever >> >>since. My >> >>>>apologies to everyone for making a bad decision. >>>> >>>>Hope this helps. >>>>thanks, >>>>-rohan >>>> >>>>On 3/7/06, *Jonathan Rosenberg* >>>> wrote: >>>> >>>> At the last IETF, there was a lot of discussion and >> >>argument around >> >>>> PRACK. The spark of this debate was the ICE >> >>specification, which had >> >>>> words in it requiring the usage of PRACK and UPDATE in >> >>order to work >> >>>> with early media. There was strong pushback from many >> >>implementors >> >>>> that >>>> anything requiring PRACK is unacceptable. Rohan put up >> >>a slide (IIRC) >> >>>> that showed the state machine in his implementation >> >>resulting from >> >>>> PRACK, and it was not pretty. >>>> >>>> So, I'd like to discuss exactly what IS the problem >> >>with PRACK? There >> >>>> are really two pieces of state machinery in play here. >> >>One piece >> >>>> is the >>>> complication that PRACK introduces into the >> >>offer/answer model. With >> >>>> PRACK, you can now get a final answer in the 18x, and >> >>then send a new >> >>>> offer in UPDATE, or even in PRACK itself. Another >> >>piece is the state >> >>>> machinery with the retransmissions itself - >> >>correlating the PRACK >> >>>> with a >>>> particular reliable provisional response and causing >> >>it to stop. >> >>>> In a chat with Flemming today, he suggested in >> >>interested remedy >> >>>> to our >>>> PRACK dilemma. Why not revise PRACK so that you can't >> >>send an offer or >> >>>> answer with it; it has no impact on the set of allowed >> >>O/A exchanges >> >>>> defined by RFC 3261. I'm not sure if that would >> >>consequently break the >> >>>> preconditions mechanism, but maybe there are some kind >> >>of offer/answer >> >>>> limitations that would simplify things. >>>> >>>> So, this is one idea. I'd like for people who have >> >>complained about >> >>>> PRACK implementations to speak up and indicate what >> >>exactly makes >> >>>> it so >>>> complicated for them. >>>> >>>> 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 >> >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 14:19:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQdZ-0008IQ-5r; Thu, 09 Mar 2006 14:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQdX-0008IK-2h for sip@ietf.org; Thu, 09 Mar 2006 14:17:23 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHQdV-0004RA-P1 for sip@ietf.org; Thu, 09 Mar 2006 14:17:23 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k29JHdWw031291 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Mar 2006 13:17:40 -0600 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60AC93F68@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60AC93F68@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <740BEB70-4CFA-47A1-9A57-B319E98D9857@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Thu, 9 Mar 2006 13:17:20 -0600 To: Samir Srivastava X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Mar 9, 2006, at 1:18 AM, Samir Srivastava wrote: > We can do for SIPS only. > > Paul said: > >> Explain to me again how you would know that reliable transport is >> used >> end to end? > Nope. sips only assures TLS as far as the proxy servicing the AOR. Now I suppose that once your dialog is established and you have a SIPS Contact: you have stronger assurances, but this isn't nailed down as that SIPS: contact could actually be a GRUU. -- 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 Mar 09 14:23:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQha-0007i9-9F; Thu, 09 Mar 2006 14:21:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQhZ-0007fV-3T for sip@ietf.org; Thu, 09 Mar 2006 14:21:33 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHQhY-0004Zv-P7 for sip@ietf.org; Thu, 09 Mar 2006 14:21:33 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k29JLnYP031313 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Mar 2006 13:21:50 -0600 In-Reply-To: <1141889747.14635.5.camel@eeek.ingate.se> References: <1141718155.10301.14.camel@eeek.ingate.se> <37FFEC27-3672-4AE7-B4A5-7E003C45B797@softarmor.com> <1141889747.14635.5.camel@eeek.ingate.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <7237F49B-C379-488C-8544-81441AD1DB60@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 Date: Thu, 9 Mar 2006 13:21:29 -0600 To: Hans Persson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Mar 9, 2006, at 1:35 AM, Hans Persson wrote: > tis 2006-03-07 klockan 11:54 -0600 skrev Dean Willis: > >>> Both these functions are nice in an ideal world, but many people >>> will have SBCs, B2BUAs, or SIP-aware firewalls in their call paths. >>> These will modify SDP and probably the Contact header. >>> >>> As far as I can see there is no discussion in the draft about this >>> at all, apart from the probably na=C4=A9ve assumption that it = shouldn't >>> happen. >> >> That's because IT SHOULDN'T HAPPEN. >> >> A B2BUA is NOT A proxy, and is NOT, in general, identity-transparent > > No, it shouldn't happen. I'm just saying that it will, in reality. > > I think it would be a good idea if new specs state explicitly if they > are going to break in common deployment scenario types instead of just > pretending that no problem exists. The problem is that ALL of our specs break when non-conformant UAs =20 are used. And B2BUAs, just like any other UA, have to be responsible =20 to the protocol. When they aren't (for example, they haven't =20 implemented an identity service with a transient relationship to the =20 original UA), then they're going to break stuff. I'm beginning to believe that service-controlling B2BUas were a =20 REALLY bad idea, proxies were a MOSTLY bad idea, and we should have =20 used a redirect-based model with negotiated traversal through =20 signaling-neutral relay elements. Like maybe P2P-SIP with ICE . . . -- 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 Mar 09 16:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSF9-0006SU-73; Thu, 09 Mar 2006 16:00:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSEX-0006Ci-82 for sip@ietf.org; Thu, 09 Mar 2006 15:59:41 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHSEV-0001QC-Pb for sip@ietf.org; Thu, 09 Mar 2006 15:59:41 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k29KxZF09091; Thu, 9 Mar 2006 15:59:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Thu, 9 Mar 2006 14:59:31 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AC948B8@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDrhuBK55/Zij/RNODB77kkQk3gAABXuNA From: "Samir Srivastava" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Pl refer my next response too. We are worried about 1xx reliability. I don't understand why we need to worry about contact. "We can do it, by adding more logic / header. UAS knows about all the hops by complete via header set inspection. When sending 1xx, it need to indicate in this new header to be defined." If UAS knows that all hops are reliable then it is not expecting PRACK, and it communicates same to UAC for not sending PRACK using the header to be defined. Though it does require modification for 100 rel tag interpretation for e2e reliable transport. IMHO we should do it. Thx Samir -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Thursday, March 09, 2006 11:17 AM To: Srivastava, Samir [SC100:8826:EXCH] Cc: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH]; IETF SIP List Subject: Re: [Sip] The Problem with PRACK On Mar 9, 2006, at 1:18 AM, Samir Srivastava wrote: > We can do for SIPS only. > > Paul said: > >> Explain to me again how you would know that reliable transport is=20 >> used end to end? > Nope. sips only assures TLS as far as the proxy servicing the AOR. =20 Now I suppose that once your dialog is established and you have a SIPS Contact: you have stronger assurances, but this isn't nailed down as that SIPS: contact could actually be a GRUU. -- 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 Mar 09 16:41:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSrM-0001AE-OV; Thu, 09 Mar 2006 16:39:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSUZ-0002hS-3y for sip@ietf.org; Thu, 09 Mar 2006 16:16:15 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHSUX-0004Dl-2f for sip@ietf.org; Thu, 09 Mar 2006 16:16:14 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 09 Mar 2006 13:13:11 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k29LDB7T014998; Thu, 9 Mar 2006 13:13:11 -0800 (PST) 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.211); Thu, 9 Mar 2006 16:13:10 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 16:13:10 -0500 Message-ID: <44109A65.9090107@cisco.com> Date: Thu, 09 Mar 2006 16:13:09 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samir Srivastava Subject: Re: [Sip] The Problem with PRACK References: <62B9B0847CC47543B6B3B5E26BD268E60AC948B8@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60AC948B8@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 21:13:10.0248 (UTC) FILETIME=[44B94E80:01C643BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Samir Srivastava wrote: > Pl refer my next response too. We are worried about 1xx reliability. I > don't understand why we need to worry about contact. > > "We can do it, by adding more logic / header. UAS knows about all the > hops by complete via header set inspection. When sending 1xx, it need to > indicate in this new header to be defined." > > If UAS knows that all hops are reliable then it is not expecting PRACK, > and it communicates same > to UAC for not sending PRACK using the header to be defined. Though it > does require modification > for 100 rel tag interpretation for e2e reliable transport. > > IMHO we should do it. *why* should we do it? The UAs still need to be prepared for cases where the path isn't e2e reliable, so they just get more complicated rather than less. I guess maybe you sometimes save a couple of messages. Is that what you are after? Paul > Thx > Samir > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, March 09, 2006 11:17 AM > To: Srivastava, Samir [SC100:8826:EXCH] > Cc: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH]; IETF SIP List > Subject: Re: [Sip] The Problem with PRACK > > > On Mar 9, 2006, at 1:18 AM, Samir Srivastava wrote: > > >>We can do for SIPS only. >> >>Paul said: >> >> >>>Explain to me again how you would know that reliable transport is >>>used end to end? >> > > Nope. sips only assures TLS as far as the proxy servicing the AOR. > Now I suppose that once your dialog is established and you have a SIPS > Contact: you have stronger assurances, but this isn't nailed down as > that SIPS: contact could actually be a GRUU. > > -- > 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 Mar 09 16:52:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHT1P-0007hA-NC; Thu, 09 Mar 2006 16:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHT1N-0007dl-VE for sip@ietf.org; Thu, 09 Mar 2006 16:50:09 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHSrj-0006IX-8u for sip@ietf.org; Thu, 09 Mar 2006 16:40:11 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FHSkd-0000Jr-Cm for sip@ietf.org; Thu, 09 Mar 2006 16:32:53 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k29LXARX000325 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Mar 2006 15:33:11 -0600 In-Reply-To: <828FF70C-E02A-4DD0-B892-F793FE54716B@softarmor.com> References: <828FF70C-E02A-4DD0-B892-F793FE54716B@softarmor.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B289687-CFA6-4461-9C54-58411D877F7E@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 9 Mar 2006 15:32:50 -0600 To: Sip X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -2.5 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Allison Mankin Subject: [Sip] Followup on WGLC for draft-ietf-sip-e2m-sec-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 On Dec 16, 2005, at 1:36 PM, Dean Willis wrote: > > Just so you folks don't think they're nothing to keep you busy over > the holidays, I'd like to start working group last call of the End > to Middle draft: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-01.txt > > I'd also like to request additional-cross area review from the > Security area on this document. > > Given the cross-area review, I'd like to conclude the WGLC by > January 20, 2006. > Okay, kids. I haven't seen a single response to this WGLC, and Kumiko tells me she hasn't either. This means one of several things: 1) You ate so much over the holidays that you forgot all about it. 2) The draft is perfect and ready to send to the IETF. 3) We just haven't thought about it enough to have an opinion. 4) We're waiting on the security review before we form our own opinion because security is complicated and scary and the practitioners have interesting hair. 5) You replied, but a GRUU ate your email. So which is it? -- 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 Mar 09 16:56:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSBi-0003Ro-IS; Thu, 09 Mar 2006 15:56:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS5I-00013F-N0; Thu, 09 Mar 2006 15:50:08 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHS5I-0007F8-KZ; Thu, 09 Mar 2006 15:50:08 -0500 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FHS5D-0005R1-22; Thu, 09 Mar 2006 15:50:08 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko20e020918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5C-00007D-Dd; Thu, 09 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 09 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-10.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 : Management Information Base for the Session Initiation Protocol (SIP) Author(s) : D. Walker, et al. Filename : draft-ietf-sip-mib-10.txt Pages : 92 Date : 2006-3-9 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy, Redirect and Registrar servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-10.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-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-mib-10.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: <2006-3-9122503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9122503.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 Thu Mar 09 17:06:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTFH-0002pN-CP; Thu, 09 Mar 2006 17:04:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTFF-0002ne-UH for sip@ietf.org; Thu, 09 Mar 2006 17:04:29 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHTFE-0000wG-MP for sip@ietf.org; Thu, 09 Mar 2006 17:04:29 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k29M4Ol13617; Thu, 9 Mar 2006 17:04:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Thu, 9 Mar 2006 16:04:20 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AC94A23@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDvksLAQUQ+mYDRH6qOp1NkEJ2OwAAMqUw From: "Samir Srivastava" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 =20 *why* should we do it? The UAs still need to be prepared for cases where the path isn't e2e reliable, so they just get more complicated rather than less. I guess maybe you sometimes save a couple of messages. Is that what you are after? Paul Yes. We have SIP over TLS e2e (SIPS) to avoid different SIP attacks eavesdropping, MiTM etc. For the cases where calls are e2e secured we don't get anything out of it, though it does make UA more complex. Going forward we will have more secure deployments. With UDP, My SIP credentials are learnt by SPAMMER, and I am bombarded with SPAMS.=20 Apart from security use cases also, If messages become larger due to different reason and TCP is used e2e, what we get there from this. Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 17:36:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTi3-0000Ra-V5; Thu, 09 Mar 2006 17:34:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTi2-0000RO-PM for sip@ietf.org; Thu, 09 Mar 2006 17:34:14 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHTi1-0003QW-Ei for sip@ietf.org; Thu, 09 Mar 2006 17:34:14 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k29MYC9E020619 for ; Thu, 9 Mar 2006 16:34:12 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k29MYCv22313; Thu, 9 Mar 2006 16:34:12 -0600 (CST) Message-ID: <4410AD64.8060207@lucent.com> Date: Thu, 09 Mar 2006 16:34:12 -0600 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Subject: [Sip] Draft on the use of TLS 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: , Content-Type: multipart/mixed; boundary="===============1512804441==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1512804441== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050407020603040603070604" This is a cryptographically signed message in MIME format. --------------ms050407020603040603070604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In another thread, it was so written: > We have SIP over TLS e2e (SIPS) to avoid different SIP attacks > eavesdropping, MiTM etc. This sort of provides me a good opening so that I stay in Dean's good books by stimulating discussions on this topic. I have published an I-D on the use of TLS in SIP, including cataloguing some open questions. The appendix contains a list of TLS test cases that may be applicable to the upcoming SIPit in Tokyo. Please see: http://www.ietf.org/internet-drafts/draft-gurbani-sip-tls-use-00.txt http://www.ietf.org/internet-drafts/draft-gurbani-sip-tls-use-00.html I have received a couple of private emails on this draft. How- ever, it would be helpful if a larger set of eyes looked at it commented on it. So, please provide any comments you may have. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms050407020603040603070604 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMDkyMjM0MTJaMCMGCSqGSIb3DQEJ BDEWBBQfY8wCxfVQnreIfL/xyeyZXQgTazBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAsucrAilxBChYWeBAV9Qd8Q2isT9UNduIXJb+WLZYw1YGuxVghlG7 4qaz64sx2R1yNj6FtjeGBal1T+rJyR7bIWiON7EZUje5wQ4HeXeOrVz1Y8CzF6h7uFrZCxXk ohzQ/yvpjKpZ/2m2Lg8WuqidOmGJjLEORl6fLxUrFmZXXkEAAAAAAAA= --------------ms050407020603040603070604-- --===============1512804441== 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 --===============1512804441==-- From sip-bounces@ietf.org Thu Mar 09 17:46:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTrz-0003t9-Nw; Thu, 09 Mar 2006 17:44:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTry-0003t4-DG for sip@ietf.org; Thu, 09 Mar 2006 17:44:30 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHTrx-0003uT-3t for sip@ietf.org; Thu, 09 Mar 2006 17:44:30 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k29MiRg4027431 for ; Thu, 9 Mar 2006 16:44:28 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k29MiRv00566; Thu, 9 Mar 2006 16:44:27 -0600 (CST) Message-ID: <4410AFCB.1060400@lucent.com> Date: Thu, 09 Mar 2006 16:44:27 -0600 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Subject: [Sip] connect-reuse-05 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="===============1241551289==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1241551289== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020502060200020706070901" This is a cryptographically signed message in MIME format. --------------ms020502060200020706070901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks: At least one person has read the -05 version of connect-reuse and commented on the list. Since this draft is also occupying SIP WG real estate during the face-2-face meeting in Dallas, it will be good to get some more comments on it. The diffs are in http://tools.ietf.org/wg/sip/draft-ietf-sip-connect-reuse/draft-ietf-sip-connect-reuse-05-from-04.diff.html Essentially, the -05 version did away with Requirement 2 from the -04 version, which caused some strain with DNS SRV and load balancing. Additionally, we have now expanded the security section, moved overlap with outbound, and added a normative behavior section. It would be much appreciated if you could kindly go through this and provide further comments. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms020502060200020706070901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMDkyMjQ0MjdaMCMGCSqGSIb3DQEJ BDEWBBSfcc6HgP3vtAQAakUqOwC3Nq2s7zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAUXPUsldpf9SNB83ksKmS1QE/1Ey7cAZC16+gGdJxTY2wEWlbn9YT ZYg997cBvcxeQgQtbZzsaUtjY8MZomYMSxVVIhptJ7jIv6UTd50yr/10OOg+dP5ME9lOLpsV PX84DHRn0BvadUtq1rQuOmzfQQysCm71l1nwrIuxih74sqMAAAAAAAA= --------------ms020502060200020706070901-- --===============1241551289== 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 --===============1241551289==-- From sip-bounces@ietf.org Thu Mar 09 17:56:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHU1R-0006OA-Gh; Thu, 09 Mar 2006 17:54:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHU1O-0006Nh-Q8 for sip@ietf.org; Thu, 09 Mar 2006 17:54:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHU1O-0004Dx-Fo for sip@ietf.org; Thu, 09 Mar 2006 17:54:14 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2006 14:54:14 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="260899137:sNHT32703014" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k29MsDYg006516 for ; Thu, 9 Mar 2006 14:54:13 -0800 (PST) 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.211); Thu, 9 Mar 2006 17:54:13 -0500 Received: from [192.168.1.101] ([10.86.240.100]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 17:54:13 -0500 Message-ID: <4410B214.30800@cisco.com> Date: Thu, 09 Mar 2006 17:54:12 -0500 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: 09 Mar 2006 22:54:13.0199 (UTC) FILETIME=[628635F0:01C643CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Sip] updated GRUU spec X-BeenThere: sip@ietf.org X-Mailman-Version: 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 submitted an update to the GRUU spec. Until it appears, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-07.txt There are some major changes in here. They are: * removal of the instance contact parameter definition, which now lives in sip-outbound. I think this was a huge improvement because of this; gruu works much better now with the dependencies reversed * elimination of the edge proxy record-route munging mess. In its place, the home proxy will rewrite the r-uri of mid-dialog requests (which will have the gruu) to equal the registered contact. This is simple to do, eliminates the spiraling problem completely, and requires no complicated procedures to detemrine when to apply it. UA's do not record-route. The mechanism does not address HA and failover for mid-dialog requests (nor does sip-outbound). We are pushing that off, since neither gruu nor sip-outbound was targeted at meeting that as a requirement. This was the conclusion a small group of us came to in some off-line discussions. * addition of a "gruu" URI parameter, to flag a URI as being a gruu. I have argued against this a lot up till now. However, seems I was in the minority so in part this reflects group consensus. When reviewing though the handling of the opaque parameter, it turned out things really fell apart in depending on supported as a clue to gruu-ness. Really the root need here is that we have a backwards compatibility issue; it would probably not have been necessary to have a 'gruu' uri param if the Contact URI had the gruu property all along. But the fact that it doesnt is a big driver here. Thus, 'gruu' is similar to 'lr' - both are URI flags meant to address this backwards compatibility issue. * as a consequence of the point above, there is virtually no mention of supported header field and its interactions with gruu * Removed requirement for inserting Require in 200 OK to REGISTER; a UA doesnt HAVE to include gruu in contacts anymore (though its still SHOULD) * removed bit about future specifications dealing with the fact that mid-dialog requests never go e2e, but always through proxies. No one is ever going to "fix" this. * gruu mechanism doesn't require the sip-outbound mechanisms to be USED with gruu; there is a normative spec dependency, which is different. gruu requires sip-outbound to be used ONLY if you are trying to register multiple contacts to the same instance, for this redundancy feature Assuming folks are happy with these changes, there are no open issues I'm aware of. 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 Thu Mar 09 18:03:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHU90-0002by-Qp; Thu, 09 Mar 2006 18:02:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHU8y-0002KW-Ff for sip@ietf.org; Thu, 09 Mar 2006 18:02:04 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHU8v-0004jD-8m for sip@ietf.org; Thu, 09 Mar 2006 18:02:04 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k29N1uF2044980; Thu, 9 Mar 2006 18:02:00 -0500 (EST) From: "Brett Tate" To: "'Samir Srivastava'" Subject: RE: [Sip] The Problem with PRACK Date: Thu, 9 Mar 2006 18:03:01 -0500 Message-ID: <004201c643cd$9db46600$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60AC94A23@zrc2hxm2.corp.nortel.com> Importance: Normal X-PMX-IsInternal: True 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 > Yes. We have SIP over TLS e2e (SIPS) to avoid different SIP=20 > attacks eavesdropping, MiTM etc. For the cases where calls=20 > are e2e secured we don't get anything out of it, though it=20 > does make UA more complex. Going forward we will have more=20 > secure deployments. With UDP, My SIP credentials are learnt=20 > by SPAMMER, and I am bombarded with SPAMS.=20 >=20 > Apart from security use cases also, If messages become larger=20 > due to different reason and TCP is used e2e, what we get=20 > there from this. Currently offer/answer usage is one reason to support 100rel on TCP and = TLS. Another reason is for better interoperability concerning clipping with devices unwilling to receive/present media until receive 18x with SDP. PRACK allows the UAS to know when the 18x has been received. Thus it = can delay sending media until it knows the UAC received the 18x. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 18:04:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHU9o-0001n4-L2; Thu, 09 Mar 2006 18:02:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHU9m-0001PM-98 for sip@ietf.org; Thu, 09 Mar 2006 18:02:54 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHU9k-0004kb-Tn for sip@ietf.org; Thu, 09 Mar 2006 18:02:54 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 09 Mar 2006 15:02:52 -0800 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 k29N2qw1021592 for ; Thu, 9 Mar 2006 15:02:52 -0800 (PST) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 15:02:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Mar 2006 15:02:51 -0800 Message-ID: <5F16CF3DBBC7EE45BF6E136F13F5CFEA01CB2381@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: response identity draft Thread-Index: AcZBC8lVPdLOYzMcRvCVV8EvlrkywQCvp0QA From: "Feng Cao \(fcao\)" To: X-OriginalArrivalTime: 09 Mar 2006 23:02:52.0316 (UTC) FILETIME=[97F12DC0:01C643CD] X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Sip] response identity 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="===============1402871274==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1402871274== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C643CD.97CD469D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C643CD.97CD469D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all,=20 Based on some comments, we extract the response identity draft from our initial work on response security. The draft is available at http://www.ietf.org/internet-drafts/draft-cao-sip-response-identity-00.t xt This draft is more or less completely rewritten. Here is the abstract: The mechanism for securely providing responder's identity in response message is missing in the current Session Initiation Protocol. Due to different call scenarios, the exact response identity is hard to guess through the existing response message. This draft describes some extensions for providing SIP response identity and two security mechanisms for verifying the integrity of response identity. It does so by defining new header fields as well as one new response code. Furthermore, the issue of how to require the presence of response identity in one SIP dialog is also discussed with one solution. Thanks, --Feng ------_=_NextPart_001_01C643CD.97CD469D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Updated connected-identity draft
Hi all,

Based on some=20 comments, we extract the response identity draft from our=20 initial work on response security. The draft is = available at http://www.ietf.org/internet-drafts/draft-cao-sip-response-ide= ntity-00.txt

This=20 draft is more or less completely rewritten. Here=20 is the abstract:

   = The=20 mechanism for securely providing responder's identity in=20 response
   message is missing in the current Session = Initiation=20 Protocol.  Due
   to different call scenarios, the = exact=20 response identity is hard to
   guess through the existing = response=20 message.  This draft describes
   some extensions for=20 providing SIP response identity and two security
   = mechanisms for=20 verifying the integrity of response identity.  It = does
   so=20 by defining new header fields as well as one new response = code.
  =20 Furthermore, the issue of how to require the presence of=20 response
   identity in one SIP dialog is also discussed = with one=20 solution.

Thanks,

--Feng

------_=_NextPart_001_01C643CD.97CD469D-- --===============1402871274== 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 --===============1402871274==-- From sip-bounces@ietf.org Thu Mar 09 18:54:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHUw8-0006LT-JV; Thu, 09 Mar 2006 18:52:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHUw7-0006LO-6X for sip@ietf.org; Thu, 09 Mar 2006 18:52:51 -0500 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 1FHUw5-000703-SU for sip@ietf.org; Thu, 09 Mar 2006 18:52:51 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2006 15:52:49 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k29Nqiw9006418 for ; Thu, 9 Mar 2006 15:52:49 -0800 (PST) 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.211); Thu, 9 Mar 2006 15:52:40 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 15:52:40 -0800 Message-Id: <4.3.2.7.2.20060309174432.029a6ce0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Mar 2006 17:52:26 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 09 Mar 2006 23:52:40.0352 (UTC) FILETIME=[8CF34A00:01C643D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Sip] SIP Location Conveyance -02 is available X-BeenThere: sip@ietf.org X-Mailman-Version: 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 I have finally revised the SIP Location Conveyance ID to -02 here: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-02.txt Here are the highlights of this version: - streamlined the doc by removing text (ultimately removing 42 pages of text). - Limited the scope of this document to SIP conveyance, meaning only how SIP can push location information. - reduced emergency calling text to just a few paragraphs now that the ECRIT WG is taking most of that topic on. - greatly reduced the number of requirements in this version. - changed the requirements groups from "UA-to-UA", "UA-to-Proxy", etc to "UAC Reqs", "UAS-Reqs" and "Proxy-Reqs" to focus on what is being asked of each SIP element. - Removed the full SIP message examples. - completed the ABNF for the Location header, including a cid-url to point at a message body part to help in parsing for location. - Deleted the call for a new 425 (Retry Location) response code, as it appears this can easily be used to spoof a UA into providing where it is inadvertently, even if the intent is legitimate by the UAC. Yesterday I received a comment on how I can change the ABNF of the Location header further, part of which made sense immediately, the remainder makes this an open issue at this moment. More comments are welcome _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 19:16:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHVH9-0000ea-SM; Thu, 09 Mar 2006 19:14:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHVH9-0000cL-8B for sip@ietf.org; Thu, 09 Mar 2006 19:14:35 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHVH7-0008Mx-Uk for sip@ietf.org; Thu, 09 Mar 2006 19:14:35 -0500 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 k2A0EU717300; Thu, 9 Mar 2006 19:14:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Thu, 9 Mar 2006 18:14:28 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0787E8A7@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDqs2+xhskKDinRn+Mmowz5ahcBwAKYw+Q From: "Francois Audet" To: "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 > I am still not following what you are suggesting. You say=20 > "deprecating=20 > the use PRACK altogether when TCP transport is used". Does=20 > that mean the=20 > UAC omits Supported:100rel if it is using TCP? Or that the=20 > UAS refuses=20 > 100rel when it receives a request over TCP? Or that 100rel is=20 > supported=20 > but still the UAS doesn't use PRACK? First one: just omit Supported 100rel when using TCP. > Its clearly possible that the access link for the UAC is TCP=20 > while that=20 > of the UAS is UDP, or visa versa. >=20 > Assuming that the e2e path is reliable without prack seems=20 > like a really=20 > bad idea. >=20 > And losing in band media can be a bad thing, such as when it=20 > is telling=20 > you why your call didn't get where it was intended to go. This can=20 > easily happen without there ever being a 200. In my mind, the really really bad idea is for proxies to downgrade=20 from TCP to UDP. It's almost as bad of an idea as recreating a transport layer in SIP instead of using a real transport layer. If I was a sneaky UAC, I could use TCP, not include Supported: 100rel, and pad my messages with empty space to ensure it's big enough to to=20 get downgraged to UDP... ;^) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 19:57:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHVuz-0004Tv-VF; Thu, 09 Mar 2006 19:55:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHVuy-0004Tq-HE for sip@ietf.org; Thu, 09 Mar 2006 19:55:44 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHVux-0001HA-93 for sip@ietf.org; Thu, 09 Mar 2006 19:55:44 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2006 16:55:43 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="260923736:sNHT29961796" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2A0tgYg000176; Thu, 9 Mar 2006 16:55:42 -0800 (PST) Received: from 10.21.81.243 ([10.21.81.243]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Mar 2006 00:55:42 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 09 Mar 2006 16:55:41 -0800 From: Cullen Jennings To: , Rohan Mahy Message-ID: Thread-Topic: Outbound and GRUU, Thread-Index: AcZD3VpkmROBmK/QEdqAnQARJEEJ/A== In-Reply-To: <440F199F.2060007@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "sip@ietf.org" Subject: [Sip] Re: Outbound and GRUU, X-BeenThere: sip@ietf.org X-Mailman-Version: 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 latest version of outbound no longer depends on GRUU. On 3/8/06 12:51 PM, "Thomas.Levy@alcatel.fr" wrote: > Cullen and Rohan, > > Could you provide explanations on relation between Outbound and GRUU. > In fact, I didn't follow whole the threads concerning the Outbound > draft, perhaps it may explain my question. > However, could you answer the following points: > In my understanding, GRUU is useful when an AOR may be registered > simultaneously on multiple UA instances. > However, the scope (and requirements) from Outbound seem different. > So, what are the motivations for making outbound fully dependent from GRUU? > For instance, in my opinion, a user registered on a natted UA could use > outbound (and thus have a persistent connection with its proxy) without > having an instance ID. > Why is it mandatory for a UA to have an Instance ID (as explained in > section 4.1) for outbound? > > Thanks for your help. > > Thomas LEVY _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 20:15:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHW9n-0004kw-Hv; Thu, 09 Mar 2006 20:11:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHW9j-0004kL-Tc for sip@ietf.org; Thu, 09 Mar 2006 20:10:59 -0500 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHW9j-0001jU-Kg for sip@ietf.org; Thu, 09 Mar 2006 20:10:59 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 19:10:59 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 09 Mar 2006 19:10:58 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 19:10:58 -0600 Message-ID: From: "Thomson, Martin" To: "James M. Polk" Date: Thu, 9 Mar 2006 19:08:51 -0600 Subject: RE: [Sip] SIP Location Conveyance -02 is available MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Mar 2006 01:10:58.0030 (UTC) FILETIME=[7CFC10E0:01C643DF] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Sip] SIP Location Conveyance -02 is available Thread-Index: AcZD1OdDU+IZVwovQWGz6skoyWO0EAACQpeA X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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="===============1859940751==" Errors-To: sip-bounces@ietf.org --===============1859940751== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSBsaWtlIHRoZSByZWR1Y3Rpb24gaW4gc2l6ZS4NCg0KT24gYSBxdWljayBzY2FuIEkgbm90aWNl IGEgZmV3IGVycm9yczoNCg0KIC0gUElERi1MTyBleGFtcGxlcyBkb24ndCBmb2xsb3cgdGhlIGZv cm0gcmVjb21tZW5kZWQgYnkgUElERi1MTyBwcm9maWxlDQogICAuIHNlZSB0aGUgbmV3IGRyYWZ0 cyBmb3IgYSBmb3JtYXQgZm9yIGJvdGggZ2VvZGV0aWMgYW5kIGNpdmljIGRhdGENCiAgIC4gdGhl IGZvcm0gb2YgcHJvdmlkZWQtYnkgaGVyZSBpcyBub3QgdmFsaWQNCiAgIC4gbmFtZXNwYWNlcyBh bmQgcHJlZml4ZXMgbmVlZCB0byBiZSBjaGVja2VkIGFuZCBjb3JyZWN0ZWQNCiAtIG11bHRpcGFy dCBNSU1FIGZvcm1hdGlvbiBpcyBpbmNvcnJlY3QgKGFuZCBjaGVjayBmb3IgJ2Jyb3VuZGFyeScp DQogLSB0aGVyZSBpcyBhIGNpcmN1bGFyIHJlZmVyZW5jZSBpbiB0aGUgQk5GICh0aGlzIGFsc28g bmVlZHMgYSByZWYuIHRvIFJGQzQyMzQpDQogLSB0aGVyZSBpcyBubyBzcGVjaWZpY2F0aW9uIGZv ciB0aGUgQk5GICdvcHRpb24tdGFnJw0KIC0gdGhlIHNlY29uZCBMb2NhdGlvbiBoZWFkZXIgZXhh bXBsZSBvbiBwYWdlIDE2IGlzbid0IGEgVVJJIChhIHJlZi4gdG8gUkZDIDM5ODYgbWlnaHQgYWxz byBiZSB1c2VmdWwpLg0KDQpJIHBvaW50ZWQgbW9zdCBvZiB0aGlzIG91dCBpbiB0aGUgbGFzdCBy ZXZpc2lvbi4NCg0KQ2hlZXJzLA0KTWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogSmFtZXMgTS4gUG9sayBbbWFpbHRvOmptcG9sa0BjaXNjby5jb21dDQo+IFNl bnQ6IEZyaWRheSwgMTAgTWFyY2ggMjAwNiAxMDo1MiBBTQ0KPiBUbzogc2lwQGlldGYub3JnDQo+ IFN1YmplY3Q6IFtTaXBdIFNJUCBMb2NhdGlvbiBDb252ZXlhbmNlIC0wMiBpcyBhdmFpbGFibGUN Cj4gDQo+IFNJUCBXRw0KPiANCj4gSSBoYXZlIGZpbmFsbHkgcmV2aXNlZCB0aGUgU0lQIExvY2F0 aW9uIENvbnZleWFuY2UgSUQgdG8gLTAyIGhlcmU6DQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi1jb252ZXlhbmNlLQ0KPiAw Mi50eHQNCj4gDQo+IEhlcmUgYXJlIHRoZSBoaWdobGlnaHRzIG9mIHRoaXMgdmVyc2lvbjoNCj4g DQo+ICAgICAtIHN0cmVhbWxpbmVkIHRoZSBkb2MgYnkgcmVtb3ZpbmcgdGV4dCAodWx0aW1hdGVs eSByZW1vdmluZyA0MiBwYWdlcw0KPiAgICAgICBvZiB0ZXh0KS4NCj4gDQo+ICAgICAtIExpbWl0 ZWQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgdG8gU0lQIGNvbnZleWFuY2UsIG1lYW5pbmcg b25seQ0KPiAgICAgICBob3cgU0lQIGNhbiBwdXNoIGxvY2F0aW9uIGluZm9ybWF0aW9uLg0KPiAN Cj4gICAgIC0gcmVkdWNlZCBlbWVyZ2VuY3kgY2FsbGluZyB0ZXh0IHRvIGp1c3QgYSBmZXcgcGFy YWdyYXBocyBub3cgdGhhdA0KPiAgICAgICB0aGUgRUNSSVQgV0cgaXMgdGFraW5nIG1vc3Qgb2Yg dGhhdCB0b3BpYyBvbi4NCj4gDQo+ICAgICAtIGdyZWF0bHkgcmVkdWNlZCB0aGUgbnVtYmVyIG9m IHJlcXVpcmVtZW50cyBpbiB0aGlzIHZlcnNpb24uDQo+IA0KPiAgICAgLSBjaGFuZ2VkIHRoZSBy ZXF1aXJlbWVudHMgZ3JvdXBzIGZyb20gIlVBLXRvLVVBIiwgIlVBLXRvLVByb3h5IiwNCj4gICAg ICAgZXRjIHRvICJVQUMgUmVxcyIsICJVQVMtUmVxcyIgYW5kICJQcm94eS1SZXFzIiB0byBmb2N1 cyBvbiB3aGF0IGlzDQo+ICAgICAgIGJlaW5nIGFza2VkIG9mIGVhY2ggU0lQIGVsZW1lbnQuDQo+ IA0KPiAgICAgLSBSZW1vdmVkIHRoZSBmdWxsIFNJUCBtZXNzYWdlIGV4YW1wbGVzLg0KPiANCj4g ICAgIC0gY29tcGxldGVkIHRoZSBBQk5GIGZvciB0aGUgTG9jYXRpb24gaGVhZGVyLCBpbmNsdWRp bmcgYSBjaWQtdXJsIHRvDQo+ICAgICAgIHBvaW50IGF0IGEgbWVzc2FnZSBib2R5IHBhcnQgdG8g aGVscCBpbiBwYXJzaW5nIGZvciBsb2NhdGlvbi4NCj4gDQo+ICAgICAtIERlbGV0ZWQgdGhlIGNh bGwgZm9yIGEgbmV3IDQyNSAoUmV0cnkgTG9jYXRpb24pIHJlc3BvbnNlIGNvZGUsIGFzDQo+ICAg ICAgIGl0IGFwcGVhcnMgdGhpcyBjYW4gZWFzaWx5IGJlIHVzZWQgdG8gc3Bvb2YgYSBVQSBpbnRv IHByb3ZpZGluZw0KPiAgICAgICB3aGVyZSBpdCBpcyBpbmFkdmVydGVudGx5LCBldmVuIGlmIHRo ZSBpbnRlbnQgaXMgbGVnaXRpbWF0ZSBieSB0aGUNCj4gICAgICAgVUFDLg0KPiANCj4gWWVzdGVy ZGF5IEkgcmVjZWl2ZWQgYSBjb21tZW50IG9uIGhvdyBJIGNhbiBjaGFuZ2UgdGhlIEFCTkYgb2Yg dGhlDQo+IExvY2F0aW9uDQo+IGhlYWRlciBmdXJ0aGVyLCBwYXJ0IG9mIHdoaWNoIG1hZGUgc2Vu c2UgaW1tZWRpYXRlbHksIHRoZSByZW1haW5kZXIgbWFrZXMNCj4gdGhpcyBhbiBvcGVuIGlzc3Vl IGF0IHRoaXMgbW9tZW50Lg0KPiANCj4gTW9yZSBjb21tZW50cyBhcmUgd2VsY29tZQ0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU2lwIG1h aWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQo+ IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2Nv bA0KPiBVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBv biBjdXJyZW50IHNpcA0KPiBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50 cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGll bnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhl cndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0 aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9o aWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ== --===============1859940751== 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 --===============1859940751==-- From sip-bounces@ietf.org Thu Mar 09 20:28:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHWPC-0002Pr-4i; Thu, 09 Mar 2006 20:26:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHWPA-0002Pm-2f for sip@ietf.org; Thu, 09 Mar 2006 20:26:56 -0500 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 1FHWP9-0002GS-O1 for sip@ietf.org; Thu, 09 Mar 2006 20:26:56 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2006 17:26:55 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="414204270:sNHT50501362" 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 k2A1QrwL009636; Thu, 9 Mar 2006 17:26:55 -0800 (PST) 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.211); Thu, 9 Mar 2006 17:26:48 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 17:26:48 -0800 Message-Id: <4.3.2.7.2.20060309192310.02fc9830@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Mar 2006 19:26:46 -0600 To: "Thomson, Martin" From: "James M. Polk" Subject: RE: [Sip] SIP Location Conveyance -02 is available In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Mar 2006 01:26:48.0228 (UTC) FILETIME=[B358C640:01C643E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Martin nothing gets by you, does it? ;-) BTW - your last response to this ID was 20 pages, so I'm making progress! I think each of the points you make are easily correctable now. Thanks for catching these. At 07:08 PM 3/9/2006 -0600, Thomson, Martin wrote: >I like the reduction in size. > >On a quick scan I notice a few errors: > > - PIDF-LO examples don't follow the form recommended by PIDF-LO profile > . see the new drafts for a format for both geodetic and civic data > . the form of provided-by here is not valid > . namespaces and prefixes need to be checked and corrected > - multipart MIME formation is incorrect (and check for 'broundary') > - there is a circular reference in the BNF (this also needs a ref. to > RFC4234) > - there is no specification for the BNF 'option-tag' > - the second Location header example on page 16 isn't a URI (a ref. to > RFC 3986 might also be useful). > >I pointed most of this out in the last revision. > >Cheers, >Martin > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Friday, 10 March 2006 10:52 AM > > To: sip@ietf.org > > Subject: [Sip] SIP Location Conveyance -02 is available > > > > SIP WG > > > > I have finally revised the SIP Location Conveyance ID to -02 here: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance- > > 02.txt > > > > Here are the highlights of this version: > > > > - streamlined the doc by removing text (ultimately removing 42 pages > > of text). > > > > - Limited the scope of this document to SIP conveyance, meaning only > > how SIP can push location information. > > > > - reduced emergency calling text to just a few paragraphs now that > > the ECRIT WG is taking most of that topic on. > > > > - greatly reduced the number of requirements in this version. > > > > - changed the requirements groups from "UA-to-UA", "UA-to-Proxy", > > etc to "UAC Reqs", "UAS-Reqs" and "Proxy-Reqs" to focus on what is > > being asked of each SIP element. > > > > - Removed the full SIP message examples. > > > > - completed the ABNF for the Location header, including a cid-url to > > point at a message body part to help in parsing for location. > > > > - Deleted the call for a new 425 (Retry Location) response code, as > > it appears this can easily be used to spoof a UA into providing > > where it is inadvertently, even if the intent is legitimate by the > > UAC. > > > > Yesterday I received a comment on how I can change the ABNF of the > > Location > > header further, part of which made sense immediately, the remainder makes > > this an open issue at this moment. > > > > More comments are welcome > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 22:04:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHXtq-00037v-TJ; Thu, 09 Mar 2006 22:02:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHXtp-00037p-It for sip@ietf.org; Thu, 09 Mar 2006 22:02:41 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHXto-00056U-8C for sip@ietf.org; Thu, 09 Mar 2006 22:02:41 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2A32U712131; Thu, 9 Mar 2006 22:02:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Thu, 9 Mar 2006 21:02:25 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60ACFC145@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDzX5frmO087QSQUue4dEB6t+B2QAFrXjA From: "Samir Srivastava" To: "Brett Tate" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Currently offer/answer usage is one reason to support 100rel on TCP and TLS. SS>> This I understood. As Christer pointed out earlier, If INVITE is empty and offer is in 1xx then we need to send answer in UPDATE. This requires changes. While we are attacking PRACK for other issues, it should be catered too.=20 Another reason is for better interoperability concerning clipping with devices unwilling to receive/present media until receive 18x with SDP. PRACK allows the UAS to know when the 18x has been received. Thus it can delay sending media until it knows the UAC received the 18x. SS>> Correct me If I am wrong, Offerer must be prepared to receive media as soon as It sent out=20 the offer. How does UAC indicate to UAS that it should send media when PRACK is received ? They are overloading 100rel. Suppose another UA doesn't support 100rel and call is setup=20 without 100 rel extension, then this UA still has media clippings because it is waiting for answer. Shouldn't these UA be fixed ?=20 Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 09 23:20:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZ5C-0000tP-RT; Thu, 09 Mar 2006 23:18:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZ5B-0000tH-VX for sip@ietf.org; Thu, 09 Mar 2006 23:18:29 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHZ5A-00079f-Lr for sip@ietf.org; Thu, 09 Mar 2006 23:18:29 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 09 Mar 2006 20:18:28 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="1783721843:sNHT31392716" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2A4IR1j026243; Thu, 9 Mar 2006 20:18:27 -0800 (PST) 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.211); Thu, 9 Mar 2006 23:18:27 -0500 Received: from [10.86.242.15] ([10.86.242.15]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 23:18:26 -0500 Message-ID: <4410FE12.3080602@cisco.com> Date: Thu, 09 Mar 2006 23:18:26 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] The Problem with PRACK References: <1ECE0EB50388174790F9694F77522CCF0787E8A7@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0787E8A7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 04:18:27.0022 (UTC) FILETIME=[ADE806E0:01C643F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: >>I am still not following what you are suggesting. You say >>"deprecating >>the use PRACK altogether when TCP transport is used". Does >>that mean the >>UAC omits Supported:100rel if it is using TCP? Or that the >>UAS refuses >>100rel when it receives a request over TCP? Or that 100rel is >>supported >>but still the UAS doesn't use PRACK? > > > First one: just omit Supported 100rel when using TCP. > > >>Its clearly possible that the access link for the UAC is TCP >>while that >>of the UAS is UDP, or visa versa. >> >>Assuming that the e2e path is reliable without prack seems >>like a really >>bad idea. >> >>And losing in band media can be a bad thing, such as when it >>is telling >>you why your call didn't get where it was intended to go. This can >>easily happen without there ever being a 200. > > > In my mind, the really really bad idea is for proxies to downgrade > from TCP to UDP. The proxy doesn't necessarily have much choice in the matter. Possibly the UAS is only accessible via UDP. Paul > It's almost as bad of an idea as recreating a transport layer in SIP > instead of using a real transport layer. > > If I was a sneaky UAC, I could use TCP, not include Supported: 100rel, > and pad my messages with empty space to ensure it's big enough to to > get downgraged to UDP... ;^) > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 10 00:35:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHaFy-0007wc-E3; Fri, 10 Mar 2006 00:33:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHaFw-0007ks-Ry for sip@ietf.org; Fri, 10 Mar 2006 00:33:40 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHaFv-0000tG-Ho for sip@ietf.org; Fri, 10 Mar 2006 00:33:40 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2A5XZs29768; Fri, 10 Mar 2006 00:33:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Thu, 9 Mar 2006 23:33:30 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60ACFC1B9@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZD+gPMiTJNZVnUTXC7aIs25mhgQAACIDpA From: "Samir Srivastava" To: "Paul Kyzivat" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 proxy doesn't necessarily have much choice in the matter. Possibly=20 the UAS is only accessible via UDP. Paul 3261 mandated UA to support TCP, quoting from section 18 page 142 " All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols. Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them.=20 " It has been around 4 years. UA MUST have TCP. We need to draw a line worrying about backward compatibility with 2543. UA is not 3261 compliant and should be fixed. If still it has only UDP, they will be few and we get gain for optimizing most of the UA supporting TCP. Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 10 02:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHbqb-0007EL-Bc; Fri, 10 Mar 2006 02:15:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHbqZ-0007C1-MM for sip@ietf.org; Fri, 10 Mar 2006 02:15:35 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHbdb-0003O4-I2 for sip@ietf.org; Fri, 10 Mar 2006 02:02:19 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVW002TFH0R7J@szxga01-in.huawei.com> for sip@ietf.org; Fri, 10 Mar 2006 15:05:15 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVW004VRH0QOG@szxga01-in.huawei.com> for sip@ietf.org; Fri, 10 Mar 2006 15:05:15 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IVW00IKZHAE5V@szxml01-in.huawei.com>; Fri, 10 Mar 2006 15:11:05 +0800 (CST) Date: Fri, 10 Mar 2006 14:54:31 +0800 From: Xiao Wang Subject: RE: [Sip] Re: Dialog usage: Forking impacts In-reply-to: <440F07B7.3020104@cisco.com> To: 'Paul Kyzivat' Message-id: <033101c6440f$7bd01330$b2b04c0a@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=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZCzkcWQTDrMdxTSrKx1Rae8z/rWwBP+6gA X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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 Inline Xiao > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, March 09, 2006 12:35 AM > To: Xiao Wang > Cc: christer.holmberg@ericsson.com; sip@ietf.org > Subject: Re: [Sip] Re: Dialog usage: Forking impacts > > > > Xiao Wang wrote: > > I think that reuse early dialog may be risk. Because SUBSCRIBE may arrive > at > > UA1 before 1xx or 2xx for the reason of net delay or lose, so UA1 doesn't > > find out a match dialog for SUBSCRIBE, finally the SUBSCRIBE will be > > dropped, and return 400. > > If UA2 sends an *confirmed* 1xx to establish the early dialog, and then > sends the subscribe after receiving confirmation (via prack) then there > is no risk. [Xiao]Right. > If UA2 sends an *unconfirmed* 1xx and then sends a subscribe within the > dialog, there is risk that UA1 won't know about the dialog. In that case > UA1 should be sending a 481 response, and UA2 will know what happened. > There should be no dropping of the subscribe. [Xiao]Oh, my meaning is SUBSCRIBE request will be failure. > Paul > > > Xiao > > > > > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: Friday, March 03, 2006 11:26 PM > >>To: Christer Holmberg (JO/LMF) > >>Cc: IETF SIP List > >>Subject: [Sip] Re: Dialog usage: Forking impacts > >> > >> > >> > >>Christer Holmberg (JO/LMF) wrote: > >> > >>>Hi, > >>> > >>>Another scenario related to the dialog usage issue: > >>> > >>>1. UA_1 sends an INVITE, which gets forked to UA_2 and UA_3. > >>> > >>>2. UA_2 establish an early dialog with UA_1 and sends a SUBSCRIBE > >>>(or any other request establishing a new dialog usage) to UA_1, > >>>establishing a dialog usage (subscribe dialog usage in case of > > > > SUBSCRIBE). > > > >>>3. UA_3 acceptes the session for the INVITE and sends 200 OK > > > > (INVITE) > > > >>>4. The forking proxy sends a CANCEL to UA_2, and forwards the 200 > >>>OK (INVITE) to UA_1. > >>> > >>>5. UA_1, when receiving the 200 OK, would normally terminate the > >>>early dialog between itself and UA_2. BUT, in this case it can't do it, > >>>because it still has an active subscription dialog usage association > >>>with UA_2, and the CANCEL sent by the proxy didn't terminate that dialog > >>>usage in UA_2 either. > >> > >>This does point up some issues with language in the RFCs. I doubt there > >>really is any such thing as an "early dialog". In reality there is only > >>one kind of dialog, but there is an "early invite dialog usage". > >> > >> > >>>Now, the dialog usages still share the same dialog, but from the UA_1 > >>>perspective each dialog usage has DIFFERENT route sets and remote > > > > targets... > > > >>Don't think I agree. Following step 3, or maybe sooner, UA1 knows there > >>are two dialogs, because it has received responses with different > >>to-tags. The early invite dialog usage with UA2 and the subscribe from > >>UA2 share one dialog, and the invite dialog usage with UA3 uses the > >>other dialog. > >> > >>There isn't anything new here due to sharing. UA2 and UA3 could have > >>both established early invite dialog usages. UA1 has to deal with two > >>dialogs in that case as well. > >> > >>The key thing in all this is that the lifetime of dialogs is not > >>explicitly managed. Rather it is reference counted based on the usages > >>that share it. > >> > >> > >>>Saying that dialog re-usage is only allowed for FULLY ESTABLISHED > >>>dialogs would of course solve this, but currentely I think it's legal > >>>from a pure SIP perspective. Or? > >> > >>This is one of the reasons why I think it is a bad idea to start putting > >>restrictions on the use of shared dialogs. As things stand, the whole > >>ediface does tie together using just a few basic principles. If you > >>support those principles, then all the different possible combinations > >>of usages will work. If you impose restrictions on the kinds of usages > >>that are allowed, you encourage implementations that implement all sorts > >>of special case logic. Figuring out what special case logic is > >>sufficient is harder than implementing the general case. > >> > >> Paul > >> > >> > >>>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 From sip-bounces@ietf.org Fri Mar 10 03:15:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHckt-0001VP-PS; Fri, 10 Mar 2006 03:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHckr-0001Uh-Sh for sip@ietf.org; Fri, 10 Mar 2006 03:13:45 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHckm-0005dq-CR for sip@ietf.org; Fri, 10 Mar 2006 03:13:45 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k2A8DcN8004523; Fri, 10 Mar 2006 09:13:38 +0100 Received: from [172.25.79.32] ([172.25.79.32]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006031009133688:7451 ; Fri, 10 Mar 2006 09:13:36 +0100 Message-ID: <44113531.8070008@alcatel.fr> Date: Fri, 10 Mar 2006 09:13:37 +0100 From: Thomas.Levy@alcatel.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.7) Gecko/20050414 X-Accept-Language: fr, en MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] Outbound and GRUU, References: <440F199F.2060007@alcatel.fr> <1141847458.3832.20.camel@cdhcp139.pingtel.com> In-Reply-To: <1141847458.3832.20.camel@cdhcp139.pingtel.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/10/2006 09:13:36, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/10/2006 09:13:38 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 You are right concenrning GRUU. But, for the Outbound draft, the Contact is not used for routing a=20 message to the UA. So, there should be no need for the Contact to be=20 globally routable. Thomas =20 Dale R. Worley a =E9crit : >On Wed, 2006-03-08 at 18:51 +0100, Thomas.Levy@alcatel.fr wrote: > =20 > >>In my understanding, GRUU is useful when an AOR may be registered=20 >>simultaneously on multiple UA instances. >> =20 >> > >GRUU can be useful even when an AOR is registered to only one UA. GRUU >is needed any time that the actual contact URI of the UA is not globally >routable. When contact URIs are not globally routable, without GRUU, >native SIP-based call control can't be made to work. So in any >situation where you are discussing outbound/STUN/ICE/etc., you can >assume that UAs are using GRUU. > >Dale > > > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 Mar 10 03:37:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHd6X-0006Wg-KO; Fri, 10 Mar 2006 03:36:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHd6O-0005sG-8P for sip@ietf.org; Fri, 10 Mar 2006 03:36:00 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHcwC-00060e-5f for sip@ietf.org; Fri, 10 Mar 2006 03:25:30 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k2A8PKcG015744; Fri, 10 Mar 2006 09:25:20 +0100 Received: from [172.25.79.32] ([172.25.79.32]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006031009251910:7576 ; Fri, 10 Mar 2006 09:25:19 +0100 Message-ID: <441137EF.50102@alcatel.fr> Date: Fri, 10 Mar 2006 09:25:19 +0100 From: Thomas.Levy@alcatel.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.7) Gecko/20050414 X-Accept-Language: fr, en MIME-Version: 1.0 To: Rohan Mahy References: <440F199F.2060007@alcatel.fr> <14203.12.151.41.2.1141859464.squirrel@12.151.41.2> In-Reply-To: <14203.12.151.41.2.1141859464.squirrel@12.151.41.2> X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/10/2006 09:25:19, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/10/2006 09:25:20 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: fluffy@cisco.com, sip@ietf.org Subject: [Sip] Re: Outbound and GRUU, X-BeenThere: sip@ietf.org X-Mailman-Version: 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, You could still have multiple flows without using an instance id. In fact, i think that the current version of the draft is confusing=20 because a reader may believe that the isntance id is used for routing=20 the messages to the UA. My opinion is that it could help understanding the Outbound solution is=20 there were 2 alternative solutions described in the document: One solution without instance id and GRUU (applicable only for AOR with=20 a single instance) The full (actual) solution with instance id and GRUU (applicable in all=20 the other cases) Any comment about that? Thomas =20 Rohan Mahy a =E9crit : >Hi Thomas, > >The instance ID is required so that the proxy can tell it is dealing with >the same UA instance. It doesn't matter if in a real deployment you might >only have one instance. Remember that with outbound you are encouraged to >use multiple flows, all with the same instance id. > >Outbound solves a general problem. Even if an instance id might not be >needed in a specific use case, it does not hurt anything to include it. > >hope this helps. >thanks, >-rohan > > > > =20 > >>Cullen and Rohan, >> >>Could you provide explanations on relation between Outbound and GRUU. >>In fact, I didn't follow whole the threads concerning the Outbound >>draft, perhaps it may explain my question. >>However, could you answer the following points: >>In my understanding, GRUU is useful when an AOR may be registered >>simultaneously on multiple UA instances. >>However, the scope (and requirements) from Outbound seem different. >>So, what are the motivations for making outbound fully dependent from >>GRUU? >>For instance, in my opinion, a user registered on a natted UA could use >>outbound (and thus have a persistent connection with its proxy) without >>having an instance ID. >>Why is it mandatory for a UA to have an Instance ID (as explained in >>section 4.1) for outbound? >> >>Thanks for your help. >> >>Thomas LEVY >> >> =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 Mar 10 03:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHd6d-00072a-Pz; Fri, 10 Mar 2006 03:36:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHd6N-0005sG-Ip for sip@ietf.org; Fri, 10 Mar 2006 03:35:59 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHcxM-00062g-W3 for sip@ietf.org; Fri, 10 Mar 2006 03:26:41 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2A8QXko029942; Fri, 10 Mar 2006 10:26:38 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 10:26:19 +0200 Received: from [172.21.35.234] ([172.21.35.234]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Mar 2006 10:26:19 +0200 Message-ID: <4411382A.2050108@nokia.com> Date: Fri, 10 Mar 2006 10:26:18 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Samir Srivastava Subject: Re: [Sip] The Problem with PRACK References: <62B9B0847CC47543B6B3B5E26BD268E60ACFC1B9@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60ACFC1B9@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 08:26:19.0328 (UTC) FILETIME=[4E7DD400:01C6441C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 ext Samir Srivastava wrote: > It has been around 4 years. UA MUST have TCP. We need to draw a line > worrying about backward compatibility with 2543. UA is not 3261 > compliant and should be fixed. If still it has only > UDP, they will be few and we get gain for optimizing most of the UA > supporting TCP. Implementing and using are two completely different things. Even if the proxy wanted to use TCP for the last hop towards the UA, it won't be able to connect to a host behind a NAT. This is what sip-outbound is trying to fix. 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 Mar 10 04:00:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdSL-00049b-OD; Fri, 10 Mar 2006 03:58:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdSK-00049W-WA for sip@ietf.org; Fri, 10 Mar 2006 03:58:41 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHdSJ-0007JJ-NZ for sip@ietf.org; Fri, 10 Mar 2006 03:58:40 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2A8wZW28030; Fri, 10 Mar 2006 03:58:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Fri, 10 Mar 2006 02:58:30 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60ACFC1F1@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZEHF8BkfLAKmK6SN+9R3yXqSuaKAAAG4dA From: "Samir Srivastava" To: "Aki Niemi" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 ext Samir Srivastava wrote: > It has been around 4 years. UA MUST have TCP. We need to draw a line=20 > worrying about backward compatibility with 2543. UA is not 3261=20 > compliant and should be fixed. If still it has only UDP, they will be=20 > few and we get gain for optimizing most of the UA supporting TCP. Implementing and using are two completely different things.=20 SS>> Agreed. Do you mean to say we are going to have *increasing* number of UAs which will be=20 ONLY supporting UDP in future, which have lot security holes because TLS is not used. Even if the proxy wanted to use TCP for the last hop towards the UA, it won't be able to connect to a host behind a NAT. This is what sip-outbound is trying to fix. SS>> How UDP is going to help here, if UA is not keeping the bindings alive. UA needs to keep=20 binding alive for every flow. Pl explain.=20 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 Mar 10 04:53:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHeHF-0001in-57; Fri, 10 Mar 2006 04:51:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHeHD-0001ho-RK for sip@ietf.org; Fri, 10 Mar 2006 04:51:15 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHeHB-0000a7-CH for sip@ietf.org; Fri, 10 Mar 2006 04:51:15 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k2A9p97H014001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Mar 2006 10:51:09 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k2A9p302024788; Fri, 10 Mar 2006 10:51:03 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k2A9ooO3024783; Fri, 10 Mar 2006 10:50:50 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] Updated connected-identity draft From: Hans Persson To: Frank Derks In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Fri, 10 Mar 2006 10:50:49 +0100 Message-Id: <1141984249.20827.30.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Fri, 10 Mar 2006 10:51:09 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org, "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 tor 2006-03-09 klockan 10:23 +0100 skrev Frank Derks: > - In 6.1/6.2/6.3 there are several occasions in which a "MUST" might > be more appropriate than a "SHOULD" and a "SHOULD" than a "MAY": > > 6.1: [...] > "... the UA MAY ..." -> "SHOULD"? > > 6.2: > "... on that dialog, the UA MAY..." -> "SHOULD"? > > 6.3: > "... on that dialog, the UA MAY ..." -> SHOULD? I agree. If we don't really care about alerting the end user of the change in identity of the party in the other end, we do we even bother writing this spec in the first place? Section 6.3 looks pretty general at first, talking about "a UA". In section 5 it says "A request in either direction after answer can indicate a change of party.", and this section (6.3) is about established calls. However, it only talks about discrepancies between the To header of the received request and the identity of the UA. Shouldn't it also talk about the From header of the sent request and the identity of the UA (the *other* UA)? Nits: Section 2, first line: The [1] reference to SIP is missing whitespace on both sides. Section 7.1, first paragraph: "conveys it identity" -> "conveys its identity". "Identity and Identity-Info header field" -> "Identity and Identity-Info header fields". Both the example in 7.1 and the one in 7.2 are inconsistent about putting a space between the message name and the message number. Sometimes it is "INVITE(1)", sometimes "INVITE (1)". I would prefer having the space in all instances. Example 7.1: The messages "200(3)" and "200(4)" in the diagram should be listed as "200 (4)" and "200 (3)" since they are traveling from the right to the left. The "ACK (6)" message would be retargeted to "ACK sip:Carol@ua2.example.com" like the INVITE, wouldn't it? Example 7.2: The left one of the "200 (3)" labels should really be "200 (4)". The re-INVITEs are labeled 11,12 but should be labeled 12,11. The same goes for the associated ACKs (15,16) which should be 16,15. Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 10 05:27:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHeof-0003yP-8U; Fri, 10 Mar 2006 05:25:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHeod-0003kL-H1 for sip@ietf.org; Fri, 10 Mar 2006 05:25:47 -0500 Received: from gw-eur4.philips.com ([161.85.125.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHeoa-0001XV-5u for sip@ietf.org; Fri, 10 Mar 2006 05:25:47 -0500 Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com [130.144.57.168]) by gw-eur4.philips.com (Postfix) with ESMTP id D6C1C4974E; Fri, 10 Mar 2006 10:25:42 +0000 (UTC) Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 7EFF64A; Fri, 10 Mar 2006 10:25:42 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur5.philips.com (Postfix) with ESMTP id 478C042; Fri, 10 Mar 2006 10:25:42 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id 7399642; Fri, 10 Mar 2006 10:25:41 +0000 (GMT) In-Reply-To: <1141984249.20827.30.camel@eeek.ingate.se> To: Hans Persson Subject: Re: [Sip] Updated connected-identity draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Frank Derks Date: Fri, 10 Mar 2006 11:24:06 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.3FP1HF291 | September 19, 2005) at 10/03/2006 11:24:28, Serialize complete at 10/03/2006 11:24:28 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org, "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 Hi Hans, > > I agree. If we don't really care about alerting the end user of the > change in identity of the party in the other end, we do we even bother > writing this spec in the first place? > I wouldn't put it that strongly, but this was certainly one of my considerations for making some of the requirements stronger than "MAY". There are however situations in which informing the "real user" is not the goal, but informing an application that acts as the user is;-) Cheers, Frank _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 10 05:50:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHfAt-0006JS-N6; Fri, 10 Mar 2006 05:48:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHfAs-0006J8-3x for sip@ietf.org; Fri, 10 Mar 2006 05:48:46 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHfAr-00025r-EM for sip@ietf.org; Fri, 10 Mar 2006 05:48:46 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id k2AAmiHm123478 for ; Fri, 10 Mar 2006 10:48:44 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2AAn7JO232654 for ; Fri, 10 Mar 2006 11:49:07 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k2AAmiJ1030386 for ; Fri, 10 Mar 2006 11:48:44 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k2AAmiU7030383 for ; Fri, 10 Mar 2006 11:48:44 +0100 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Fri, 10 Mar 2006 12:49:05 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 10/03/2006 12:49:07, Serialize complete at 10/03/2006 12:49:07 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [Sip] Case sensitivity of user name - why RFC 3261 is more strict then RFC 2543 [RESEND] X-BeenThere: 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="===============0328581216==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0328581216== Content-Type: multipart/alternative; boundary="=_alternative 003B5489C225712D_=" This is a multipart message in MIME format. --=_alternative 003B5489C225712D_= Content-Type: text/plain; charset="US-ASCII" Unless I am completely missing something I think that it is an important issue. RFC 3261 seem to imply that user name in SIP is case sensitive while email and even RFC 2543 do not impose this restriction. Unless implementations ignore RFC 3261 in this case there may be a usage issue. Most SIP implementations are connected to email systems and users are used to write the user name in a free way without regarding case. When a user put a name in e.g. a dialogue box for INVITE I am not sure that we can expect that the user will match the way that the other user will register in their proxy. Can someone clarify this issue? Below are excerpts from the relevant RFCs: RFC 2543 (section 2, page 24) allows for: SIP URLs are case-insensitive, so that for example the two URLs sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All URL parameters are included when comparing SIP URLs for equality. That is RFC 2543 does not care about the case of the user name. RFC 3261 says in section 19.14: SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) sip:alice@AtLanTa.CoM;Transport=UDP That is we are having a stricter rules for user name comparison. Does anyone remember why it was done? I could not find a reference to this in the list of changes from RFC 2543 at the end of RFC 3261. In email as far as I know user names are NOT case sensitive. RFC 821 only says: Commands and replies are not case sensitive. That is, a command or reply word may be upper case, lower case, or any mixture of upper and lower case. Note that this is not true of mailbox user names. For some hosts the user name is case sensitive, and SMTP implementations must take case to preserve the case of user names as they appear in mailbox arguments. Host names are not case sensitive. So for email servers need only to preserve the name casing. Thanks --Avshalom --=_alternative 003B5489C225712D_= Content-Type: text/html; charset="US-ASCII"
Unless I am completely missing something I think that it is an important issue.
RFC 3261 seem to imply that user name in SIP is case sensitive while email and even RFC 2543
do not impose this restriction.
Unless implementations ignore RFC 3261 in this case there may be a usage issue.
Most SIP implementations are connected to email systems and users are used to write the user name in a free way
without regarding case. When a user put a name in e.g. a dialogue box for INVITE I am not sure that we can expect that
the user will match the way that the other user will register in their proxy.

Can someone clarify this issue?

Below are excerpts from the relevant RFCs:


RFC 2543 (section 2, page 24) allows for:

   SIP URLs are case-insensitive, so that for example the two URLs
   sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent.  All
   URL parameters are included when comparing SIP URLs for equality.

That is RFC 2543 does not care about the case of the user name.

RFC 3261 says in section 19.14:

   SIP:ALICE@AtLanTa.CoM;Transport=udp             (different usernames)
   sip:alice@AtLanTa.CoM;Transport=UDP

That is we are having a stricter rules for user name comparison.

Does anyone remember why it was done? I could not find a reference to this in
the list of changes from RFC 2543 at the end of RFC 3261.

In email as far as I know user names are NOT case sensitive. RFC 821 only says:

   Commands and replies are not case sensitive.  That is, a command or
   reply word may be upper case, lower case, or any mixture of upper and
   lower case.  Note that this is not true of mailbox user names.  For
   some hosts the user name is case sensitive, and SMTP implementations
   must take case to preserve the case of user names as they appear in
   mailbox arguments.  Host names are not case sensitive.

So for email servers need only to preserve the name casing.

Thanks
--Avshalom

--=_alternative 003B5489C225712D_=-- --===============0328581216== 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 --===============0328581216==-- From sip-bounces@ietf.org Fri Mar 10 07:08:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHgOH-0003ur-Tv; Fri, 10 Mar 2006 07:06:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHgOH-0003um-0P for sip@ietf.org; Fri, 10 Mar 2006 07:06:41 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHgOF-000481-Hj for sip@ietf.org; Fri, 10 Mar 2006 07:06:40 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IVW00701USFW0@siemenscomms.co.uk> for sip@ietf.org; Fri, 10 Mar 2006 12:02:40 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IVW0067IUPUZB@siemenscomms.co.uk>; Fri, 10 Mar 2006 12:01:06 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Mar 2006 12:03:51 +0000 Content-return: allowed Date: Fri, 10 Mar 2006 12:03:50 +0000 From: "Elwell, John" Subject: RE: [Sip] Updated connected-identity draft To: Hans Persson , Frank Derks Message-id: <50B1CBA96870A34799A506B2313F266708572246@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 Hans, Thanks for your comments. See below. John > -----Original Message----- > From: Hans Persson [mailto:hasse@ingate.com] > Sent: 10 March 2006 09:51 > To: Frank Derks > Cc: sip@ietf.org; Elwell, John > Subject: Re: [Sip] Updated connected-identity draft > > tor 2006-03-09 klockan 10:23 +0100 skrev Frank Derks: > > > - In 6.1/6.2/6.3 there are several occasions in which a > "MUST" might > > be more appropriate than a "SHOULD" and a "SHOULD" than a "MAY": > > > > 6.1: > [...] > > "... the UA MAY ..." -> "SHOULD"? > > > > 6.2: > > "... on that dialog, the UA MAY..." -> "SHOULD"? > > > > 6.3: > > "... on that dialog, the UA MAY ..." -> SHOULD? > > I agree. If we don't really care about alerting the end user of the > change in identity of the party in the other end, we do we even bother > writing this spec in the first place? [JRE] I tend to agree too. > > > Section 6.3 looks pretty general at first, talking about "a UA". In > section 5 it says "A request in either direction after answer can > indicate a change of party.", and this section (6.3) is about > established calls. However, it only talks about discrepancies between > the To header of the received request and the identity of the UA. > Shouldn't it also talk about the From header of the sent > request and the > identity of the UA (the *other* UA)? [JRE] I guess you mean a discrepancy between the From header of the sent INVITE request and the current identity of the (local) UA. In this case, again subject to the option tag, we could send a revised URI in the From header field - this does seem to be missing. > > > Nits: [JRE] I will attend to these when I next update the document. > > Section 2, first line: The [1] reference to SIP is missing > whitespace on > both sides. > > Section 7.1, first paragraph: "conveys it identity" -> "conveys its > identity". "Identity and Identity-Info header field" -> "Identity and > Identity-Info header fields". > > Both the example in 7.1 and the one in 7.2 are inconsistent about > putting a space between the message name and the message number. > Sometimes it is "INVITE(1)", sometimes "INVITE (1)". I would prefer > having the space in all instances. > > Example 7.1: The messages "200(3)" and "200(4)" in the > diagram should be > listed as "200 (4)" and "200 (3)" since they are traveling from the > right to the left. > The "ACK (6)" message would be retargeted to "ACK > sip:Carol@ua2.example.com" like the INVITE, wouldn't it? > > Example 7.2: The left one of the "200 (3)" labels should > really be "200 > (4)". The re-INVITEs are labeled 11,12 but should be labeled > 12,11. The > same goes for the associated ACKs (15,16) which should be 16,15. > > Hans > > -- > Hans Persson Ingate - Firewalls with SIP & NAT > Ingate Systems AB +46 13 210877 http://www.ingate.com/ > > Private: http://www.lysator.liu.se/~unicorn/ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 10 07:14:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHgTh-0007hl-Ez; Fri, 10 Mar 2006 07:12:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHgTf-0007hK-Nf for sip@ietf.org; Fri, 10 Mar 2006 07:12:15 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHgTe-0004Qe-9S for sip@ietf.org; Fri, 10 Mar 2006 07:12:15 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k2ACCCu7020461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Mar 2006 13:12:13 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k2ACC7Iu028370; Fri, 10 Mar 2006 13:12:07 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k2ACC2MX028368; Fri, 10 Mar 2006 13:12:02 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: RE: [Sip] Updated connected-identity draft From: Hans Persson To: "Elwell, John" In-Reply-To: <50B1CBA96870A34799A506B2313F266708572246@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266708572246@ntht201e.siemenscomms.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Fri, 10 Mar 2006 13:12:01 +0100 Message-Id: <1141992721.20827.31.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Fri, 10 Mar 2006 13:12:13 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Frank Derks , 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 fre 2006-03-10 klockan 12:03 +0000 skrev Elwell, John: > > Section 6.3 looks pretty general at first, talking about "a UA". In > > section 5 it says "A request in either direction after answer can > > indicate a change of party.", and this section (6.3) is about > > established calls. However, it only talks about discrepancies between > > the To header of the received request and the identity of the UA. > > Shouldn't it also talk about the From header of the sent > > request and the > > identity of the UA (the *other* UA)? > > [JRE] I guess you mean a discrepancy between the From header of the sent > INVITE request and the current identity of the (local) UA. In this case, > again subject to the option tag, we could send a revised URI in the From > header field - this does seem to be missing. Yes, exactly. Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 10 07:25:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHger-0004WY-5N; Fri, 10 Mar 2006 07:23:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHgeq-0004NQ-1H for sip@ietf.org; Fri, 10 Mar 2006 07:23:48 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHgeo-0004u9-IX for sip@ietf.org; Fri, 10 Mar 2006 07:23:48 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2ACM3w5000435; Fri, 10 Mar 2006 14:22:04 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 14:23:44 +0200 Received: from [172.21.35.234] ([172.21.35.234]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Mar 2006 14:23:43 +0200 Message-ID: <44116FCA.6010109@nokia.com> Date: Fri, 10 Mar 2006 14:23:38 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Samir Srivastava Subject: Re: [Sip] The Problem with PRACK References: <62B9B0847CC47543B6B3B5E26BD268E60ACFC1F1@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60ACFC1F1@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 12:23:43.0969 (UTC) FILETIME=[78F58D10:01C6443D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Inline. ext Samir Srivastava wrote: > ext Samir Srivastava wrote: >> It has been around 4 years. UA MUST have TCP. We need to draw a line >> worrying about backward compatibility with 2543. UA is not 3261 >> compliant and should be fixed. If still it has only UDP, they will be >> few and we get gain for optimizing most of the UA supporting TCP. > > Implementing and using are two completely different things. > > SS>> Agreed. Do you mean to say we are going to have *increasing* number > of UAs which will be > ONLY supporting UDP in future, which have lot security holes > because TLS is not used. I think (and hope) there will be an increasing number of UAs both supporting *and* using TCP and TLS in the future. > Even if the proxy wanted to use TCP for the last hop towards the UA, it > won't be able to connect to a host behind a NAT. This is what > sip-outbound is trying to fix. > > SS>> How UDP is going to help here, if UA is not keeping the bindings > alive. UA needs to keep > binding alive for every flow. Pl explain. But if there is no contact registered for that UA that supports TCP, then the proxy is out of luck and can only downgrade to UDP. There's actually a wide range of associated problems with UAs I've used. For example, some might allow you to switch over to using TCP, but after that, the UA will only ever use TCP -- for registrations and invites alike -- leaving domains that only accept UDP unreachable. So again, implementing and using (let alone using wisely) are two entirely different things. Cheers, Aki Cheers, Aki > > 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 Mar 10 08:31:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhgP-0006y6-C1; Fri, 10 Mar 2006 08:29:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhgN-0006vh-4A for sip@ietf.org; Fri, 10 Mar 2006 08:29:27 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHhgL-0006Vb-Sa for sip@ietf.org; Fri, 10 Mar 2006 08:29:27 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k2ADTKXQ083174; Fri, 10 Mar 2006 08:29:25 -0500 (EST) From: "Brett Tate" To: "'Samir Srivastava'" Subject: RE: [Sip] The Problem with PRACK Date: Fri, 10 Mar 2006 08:30:24 -0500 Message-ID: <000001c64446$c9ed4f10$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60ACFC145@zrc2hxm2.corp.nortel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 > Another reason is for better interoperability concerning=20 > clipping with devices unwilling to receive/present media=20 > until receive 18x with SDP. PRACK allows the UAS to know when=20 > the 18x has been received. Thus it can delay sending media=20 > until it knows the UAC received the 18x. >=20 > SS>> Correct me If I am wrong, Offerer must be prepared=20 > to receive media as soon as It sent out the offer.=20 I agree. Unfortunately some clients and SBCs, require the offer/answer handshake before presenting the media. This is usually because of = security concerns. And various working groups are attempting to ready these = security/clipping concerns. However PRACK helps address the situation until a better = solution is found. > How does UAC indicate to UAS that it should send media=20 > when PRACK is received ? The clients (and SBCs) usually can't without requiring 1 or more offer/answer handshakes or additional sip extensions. However this type = of security/clipping concern was one thing which led to the RFCs indicating things like offer in 18x and answer within PRACK. And unless someone standardizes a way to clearly indicate if SDP is = offer or answer, indicating an answer within an UPDATE would likely not be a desirable replacement to PRACK containing answer because of potential = race conditions. > They are overloading 100rel.=20 The UAS is just taking advantage of the knowledge provided by receiving PRACK. And it might act the same way concerning ACK. > Suppose another UA doesn't support 100rel and call=20 > is setup without 100 rel extension, then this UA=20 > still has media clippings because it is waiting for=20 > answer. Shouldn't these UA be fixed ?=20 Various working groups are attempting to remedy these security/clipping concerns. Maybe someday operators will no longer need/desire the = security functionality provided by the offer/answer handshake. Until then, PRACK provides some benefit within such an environment. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 10 11:04:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHk4Z-0006Pq-HT; Fri, 10 Mar 2006 11:02:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHk4W-0006P0-Nv for sip@ietf.org; Fri, 10 Mar 2006 11:02:33 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHk4W-00036S-BW for sip@ietf.org; Fri, 10 Mar 2006 11:02:32 -0500 Received: from [131.161.248.88] (open-131-161-248-88.cliq.com [131.161.248.88]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k2AG2OF17828; Fri, 10 Mar 2006 08:02:24 -0800 In-Reply-To: <441137EF.50102@alcatel.fr> References: <440F199F.2060007@alcatel.fr> <14203.12.151.41.2.1141859464.squirrel@12.151.41.2> <441137EF.50102@alcatel.fr> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0c50f5059ed82a8f70483a83e1e551d6@ekabal.com> Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Date: Fri, 10 Mar 2006 08:02:25 -0800 To: Thomas.Levy@alcatel.fr X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org Subject: [Sip] Re: Outbound and GRUU, X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Thomas, FYI: The latest outbound draft does not depend on GRUU. Sorry, but there is no good reason to introduce a second solution. The=20= first solution is general and the second one is fully covered by the=20 first. The outbound draft is already long enough, and creating and=20 using an instance-id is not a burden. Generating one from your MAC=20 address takes less than lines of code. Then you just include it in=20 your registers. thanks, -rohan On Mar 10, 2006, at 0:25, Thomas.Levy@alcatel.fr wrote: > Hi Rohan, > > You could still have multiple flows without using an instance id. > In fact, i think that the current version of the draft is confusing=20 > because a reader may believe that the isntance id is used for routing=20= > the messages to the UA. > My opinion is that it could help understanding the Outbound solution=20= > is there were 2 alternative solutions described in the document: > One solution without instance id and GRUU (applicable only for AOR=20 > with a single instance) > The full (actual) solution with instance id and GRUU (applicable in=20 > all the other cases) > > Any comment about that? > > Thomas > Rohan Mahy a =E9crit : > >> Hi Thomas, >> >> The instance ID is required so that the proxy can tell it is dealing=20= >> with >> the same UA instance. It doesn't matter if in a real deployment you=20= >> might >> only have one instance. Remember that with outbound you are=20 >> encouraged to >> use multiple flows, all with the same instance id. >> >> Outbound solves a general problem. Even if an instance id might not=20= >> be >> needed in a specific use case, it does not hurt anything to include=20= >> it. >> >> hope this helps. >> thanks, >> -rohan >> >> >> >> >>> Cullen and Rohan, >>> >>> Could you provide explanations on relation between Outbound and = GRUU. >>> In fact, I didn't follow whole the threads concerning the Outbound >>> draft, perhaps it may explain my question. >>> However, could you answer the following points: >>> In my understanding, GRUU is useful when an AOR may be registered >>> simultaneously on multiple UA instances. >>> However, the scope (and requirements) from Outbound seem different. >>> So, what are the motivations for making outbound fully dependent = from >>> GRUU? >>> For instance, in my opinion, a user registered on a natted UA could=20= >>> use >>> outbound (and thus have a persistent connection with its proxy)=20 >>> without >>> having an instance ID. >>> Why is it mandatory for a UA to have an Instance ID (as explained in >>> section 4.1) for outbound? >>> >>> Thanks for your help. >>> >>> Thomas LEVY >>> >>> >> >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 10 11:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkRU-0001Hs-FI; Fri, 10 Mar 2006 11:26:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkRS-0001Hk-TM for sip@ietf.org; Fri, 10 Mar 2006 11:26:14 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHkRP-00043W-Hs for sip@ietf.org; Fri, 10 Mar 2006 11:26:14 -0500 Received: from dhcp-192.lkp.ingate.se (dhcp-192.lkp.ingate.se [193.180.23.192]) (authenticated bits=0) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k2AGPfjN000303 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Mar 2006 17:25:51 +0100 Subject: Re: [Sip] Followup on WGLC for draft-ietf-sip-e2m-sec-01.txt From: Hans Persson To: Dean Willis , ono.kumiko@lab.ntt.co.jp, tachimoto.shinya@lab.ntt.co.jp In-Reply-To: <2B289687-CFA6-4461-9C54-58411D877F7E@softarmor.com> References: <828FF70C-E02A-4DD0-B892-F793FE54716B@softarmor.com> <2B289687-CFA6-4461-9C54-58411D877F7E@softarmor.com> Content-Type: text/plain; charset=UTF-8 Organization: Ingate Systems Date: Fri, 10 Mar 2006 17:25:39 +0100 Message-Id: <1142007939.9980.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Fri, 10 Mar 2006 17:26:10 +0100 (CET) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by usagi.ingate.se id k2AGPfjN000303 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2 Cc: Sip , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org tor 2006-03-09 klockan 15:32 -0600 skrev Dean Willis: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-01.txt > > Okay, kids. I haven't seen a single response to this WGLC, and Kumiko =20 > tells me she hasn't either. This means one of several things: In my case, the reason is > 1) You ate so much over the holidays that you forgot all about it. Since the holidays are a bit off by now (even though we still have the slow... :-/ ), I read through the draft just now. I'm not very good with encryption and such, so therefore I'm changing my reason to > 3) We just haven't thought about it enough to have an opinion. I'll try to give it some more thought, but this'll probably be an RFC before something useful comes out of that... While reading the draft, I did various minor nit changes (mostly, if not entirely, editorial). I'm attaching them in the form of a diff below (I don't have time to convert them to a more friendly format right now). Hopefully, someone else has a more educated opinion about the workings of the draft than I do. Until then, =E3=81=A7=E3=81=AF=E3=81=BE=E3=81=9F=E3=80=82 Hans --- draft-ietf-sip-e2m-sec-01.txt 2005-10-31 16:18:19.000000000 +0100 +++ draft-ietf-sip-e2m-sec-01-hp.txt 2006-03-10 16:58:18.273167367 +0100 @@ -136,7 +136,7 @@ The proposed mechanisms are based on S/MIME [3], since the major requirement is to have little impact on standardized end-to-end security mechanisms defined in [1], the way of handling S/MIME-secure - messages. The mechanisms consist of generating S/MIME-secured + messages. The mechanisms consist of generating an S/MIME-secured message body and indicating the target message body for a proxy server selected by the UA. In addition, this document describes a mechanism for a UA to discover the intermediary which needs to @@ -176,7 +176,7 @@ of each recipient or the shared keys between the UA and each recipient. =20 - If the encrypted data is destined for one or more than one proxy + If the encrypted data is destined for one or more proxy server(s), the recipient list MUST contain only the proxy server(s). If the same encrypted data is shared with the user agent server (UAS) and proxy servers, the recipient list (the "recipientInfos" field) @@ -200,7 +200,7 @@ =20 Figure 1: An Example Structure of EnvelopedData for Sharing =20 - If there are multiple pieces encrypted data destined for each proxy + If there are multiple pieces of encrypted data destined for each proxy server, the recipient list in each piece of encrypted data MUST contain the relevant proxy server. If a piece of encrypted data is destined for a proxy server and another piece of encrypted data for @@ -260,7 +260,7 @@ =20 Note: There are other mechanisms which can provide data integrity, such as S/MIME CMS AuthenticatedData, which requires that a UA - obtains the credential of the recipient, that is a proxy server, + obtains the credentials of the recipient, that is a proxy server, in advance. However, this is not used in [1] and require a mechanism to securely transmit the credential from the proxy server to the UA. Thus, this document does not describe the use @@ -299,7 +299,7 @@ other hand, the indication for signed data is usually useless because any entities can verify the signed data and the signed data is always protecting the whole message body. Therefore, a UA is NOT - RECOMMENDED to set a indication using the "Proxy-Required-Body" + RECOMMENDED to set an indication using the "Proxy-Required-Body" header for signed data. =20 Note: There were three other options to label a body: a new SIP @@ -319,7 +319,7 @@ indication. Even if a UA indicates a proxy server that is not along the signaling path, or that doesn't support this mechanism, the UA doesn't have any error response. The UA can only acknowledge the - proxy server's behavior or compliance through the service which + proxy server's behavior or compliance through that the service which requires proxy server's inspection of the message body fails. =20 Note: Is "Proxy-Required-Body" an appropriate name? "Proxy- @@ -349,9 +349,9 @@ servers. One is by receiving an error response from the proxy servers. The error response shows the violation of the policies, then a UAC can learn them. However, it is not applicable to the UAS - because there is no way to react a response message. Alternatively, - a policy server can provide a UAC and the UAS a package mentioning - proxy's policy as described in [11]. When a proxy server needs to + because there is no way to react to a response message. Alternatively, + a policy server can provide a UAC and the UAS with a package mentioning + the proxy's policy as described in [11]. When a proxy server needs to inspect the message body contained in the response, it needs to learn the policies from a policy server before sending the response. This document covers only the former. @@ -359,10 +359,10 @@ 4.1 Discovery with Error Responses =20 When the proxy server receives a request that can not be accepted due - to its condition, the proxy server MUST reject with an error + to its condition, the proxy server MUST reject it with an error response. If the request contains encrypted data and the proxy server cannot view the message body that has to be viewed in order to - proceed, the proxy server MUST reject with a new error response, 496 + proceed, the proxy server MUST reject the request with a new error response, 496 (Proxy Indecipherable). The proxy's public key certificate and Content-Type to be viewed SHOULD be contained with the error response. The proxy's public key certificate SHOULD be set as an @@ -375,14 +375,14 @@ target Content-Type that the proxy server wants to view in the Warning header, if they exist. =20 - Until the previous version, 493 (Undecipherable) error response + Until the previous version, the 493 (Undecipherable) error response had been proposed to be shared by the UAS and a proxy server. However, the reactions requesting the UAC are different, as pointed out in the SIP mailing list. On receiving the error response from the UAS, the UAC should totally renew - "recipientInfos" by encrypted CEK with the KEK obtained from the + "recipientInfos" by encrypting(?) the CEK with the KEK obtained from the error response. On the other hand, on receiving the error - response from the proxy server, the UAC first should analyze the + response from the proxy server, the UAC should first analyze the feature of the message body and the proxy-requiring Content-Type obtained from the Warning header. If the UAC decides to share the =20 @@ -394,7 +394,7 @@ =20 =20 message body with the UAS and the proxy server, the UAC will reuse - the "recipientInfos" of the previous request and add encrypted CEK + the "recipientInfos" of the previous request and add an encrypted CEK with the proxy's KEK obtained from the error response to it. If the UAC decides to send two parts of the message body separately, the UAC will add the EnvelopedData that contains a message body @@ -403,7 +403,7 @@ =20 If a digital signature is not attached to the message body in the request and the proxy server requires the integrity check, the proxy - server MUST reject with a 495 (Signature Required) error response. + server MUST reject the request with a 495 (Signature Required) error response. This error response does not contain Content-Type that is required signature, since the attached signature to the whole body is always required. The proxy server MAY attach the signature to a "message/ @@ -418,7 +418,7 @@ server SHOULD send an error response only for requesting disclosure. After receiving a request message including encrypted data destined for the proxy server, it finds out whether the message has a - signature attached and SHOULD send an error response for requesting + signature attached and SHOULD send an error response for requesting a signature when the message lacks it. =20 There are two ways to encrypt and sign data: encrypt data after @@ -428,8 +428,8 @@ response requiring the signature for the data prior to the encryption, if the encryption is needed. =20 - This discovery mechanism requires two more message exchange for an - error condition per each proxy server in the signaling path in order + This discovery mechanism requires two more message exchanges for an + error condition for each proxy server in the signaling path in order to establish a session between UAs. Since this causes a delay in session establishment, it is desirable that the UAs learn the security policies of the proxy servers in advance. @@ -464,7 +464,7 @@ =20 5.1 UAC Behavior =20 - When a UAC (UA #1) sends an INVITE or a MESSAGE request including + When a UAC (UA #1) sends an INVITE or a MESSAGE request including an encrypted message body for end-to-middle confidentiality, it MUST generate S/MIME CMS EnvelopedData, and SHOULD specify the hostname of Proxy #1 and Content-ID of the S/MIME CMS EnvelopedData which is to @@ -472,8 +472,8 @@ =20 If UA #1 decides to share the message body with the UAS (UA #2) and the proxy server (Proxy #1) that requires the inspection of the - message body, UA #1 MUST list encrypted CEK with the Proxy #1's KEK - and encrypted CEK with the UA #2's KEK at the "recipientInfos" of the + message body, UA #1 MUST list encrypted CEK with Proxy #1's KEK + and encrypted CEK with UA #2's KEK in the "recipientInfos" section of the CMS EnvelopedData. If UA #1 decides to set the message body separately, UA #1 MUST structure a "multipart/mixed" body that contains two CMS EnvelopedData: one encrypted for UA #2 and another @@ -485,12 +485,12 @@ parameter, since the default value is "required" as specified in [1]. =20 This separate structure is useful when keying materials, such as - keys used for Secure RTP (SRTP), are included in the SDP[14], UA + keys used for Secure RTP (SRTP), are included in the SDP[14] and UA #1 does not want to show the keying materials to Proxy #1, although Proxy #1 needs to view the SDP for the firewall traversal service. =20 - If UA #1 sends an INVITE request including encrypted the SDP just for + If UA #1 sends an INVITE request including encrypted SDP just for end-to-end, being unaware of the service provided by Proxy #1 that requires the inspection of the message body, UA #1 will get a 496 (Proxy Indecipherable) error response with the public key of Proxy #1 @@ -508,18 +508,18 @@ 496 (Proxy Indecipherable) error response with the public key of Proxy #1 and no Warning header requiring Content-Type. =20 - By obtaining the error response, UA #1 acknowledges that Proxy #1 + When receiving the error response, UA #1 learns that Proxy #1 requires the disclosure of a partial or the whole message body. If UA #1 decides to meet the requirement of Proxy #1, UA #1 generates CMS EnvelopedData and sets the "Proxy-Required-Body" header as - described above. If the UA #1 decides to share the message body with - the UA #2 and Proxy #1, UA #1 MUST update the "recipientInfos" of the + described above. If UA #1 decides to share the message body with + UA #2 and Proxy #1, UA #1 MUST update the "recipientInfos" of the previous request by adding encrypted CEK with Proxy #1's KEK obtained from the error response. If UA #1 decides to set the message body separately for Proxy #1, UA #1 MUST structure a "multipart/mixed" body by adding the CMS EnvelopedData for Proxy #1. =20 - When UA #1 sends a request message of which message body needs end- + When UA #1 sends a request message where the message body needs end- to-middle integrity, it SHOULD generate S/MIME CMS SignedData to attach a digital signature. UA #1 MAY specify the hostname of Proxy #1 and Content-ID of the CMS SignedData to be validated by Proxy #1 @@ -540,9 +540,9 @@ confidentiality and integrity for the message body, it SHOULD first generate S/MIME CME SignedData to attach the digital signature for the content, and then generate S/MIME EnvelopedData to encrypt the - CMS SignedData. UA#1 SHOULD specify the hostname of Proxy#1 and the + CMS SignedData. UA #1 SHOULD specify the hostname of Proxy #1 and the Content-ID of the CMS EnvelopedData destined for Proxy #1 in the - "Proxy-Required-Body". UA#1 also MAY specify the Content-ID of the + "Proxy-Required-Body". UA #1 MAY also specify the Content-ID of the CMS SignedData following the Content-ID of the CMS EnvelopedData in the header. =20 @@ -551,7 +551,7 @@ outside is easily detachable. =20 If UA #1 needs the confidentiality of the SDP, and UA #1 knows that - Proxy #1 needs to view the both SDPs in an INVITE request and a 200 + Proxy #1 needs to view both the SDPs in an INVITE request and a 200 OK response for the firewall traversal service, UA #1 MAY use the CEK =20 =20 @@ -619,12 +619,12 @@ =20 requests or responses. By checking the "Proxy-Required-Body" header in the receiving request, UA #2 MAY know the destination (Proxy #1) - and the Content-Type to be disclosed. If UA #2 accept the + and the Content-Type to be disclosed. If UA #2 accepts the disclosure, it MAY keep the CEK with the identifier specified in the "unprotectedAttrs" attribute. If UA #2 receives an INVITE message specifying the CEK reuse, UA #2 MAY reuse the CEK (CEK #1) to encrypt a new CEK (CEK #2) for encrypting the SDP in a 200 OK response as - showed in Figure 5 + showed in Figure 5: =20 +-------------------------------------------------------------+ | The "encryptedContentInfo" field | @@ -642,8 +642,8 @@ Even when UA #2 receives a request that does not use S/MIME, UA #2 sometimes needs end-to-middle confidentiality for the message body in a response, for example, the SDP offer/answer in a 200 response and - ACK request. The behavior for generating S/MIME CMS data is the same - as how UA #1 operates as described in Section 5.1, while the behavior + ACK request. The behavior for generating S/MIME CMS data is similar + to how UA #1 operates as described in Section 5.1, while the behavior for discovering the security policies of Proxy #1 can not be not supported. =20 @@ -651,12 +651,12 @@ =20 When the proxy server supporting this mechanism for its own security policies (Proxy #1) receives a message, it MUST inspect the "Proxy- - Required-Body" header(s). If the header includes the Proxy #1's + Required-Body" header(s). If the header includes Proxy #1's hostname, Proxy #1 MUST inspect the body indicated by the "content-id" parameter. If multiple "content-id" parameters exist in the header, Proxy #1 MUST inspect the bodies in order. Even if the - header does not include the Proxy #1's hostname, nor the header - exists, Proxy #1 MAY view the message body following its own security + header does not include Proxy #1's hostname or the header doesn't + exist, Proxy #1 MAY view the message body following its own security policies. =20 When the indicated body is CMS EnvelopedData, Proxy #1 MUST try to @@ -664,7 +664,7 @@ data for Proxy #1, Proxy #1 will succeed in obtaining the CEK to decrypt the encrypted content at the "encryptedContentInfo" field. =20 - If Proxy #1 fails to decrypt the message body that is required to + If Proxy #1 fails to decrypt the message body that it is required to =20 =20 =20 @@ -686,15 +686,18 @@ information only for UA #2, if UA #1 sets different port information for UA #2 and Proxy #1 separately on purpose or not. The firewall traversal service for UA #1 will fail. However, - Proxy #1 care about the information even only for UA #2, if Proxy + Proxy #1 cares about the information even only for UA #2, if Proxy #1 provides a call admission control using codec information in SDP. Proxy #1 needs to view the SDP destined not only for itself, but also the SDP destined for UA #2 in order to confirm that both - of the codec information are the same. In other words, Proxy #1 + sets of codec information are the same. In other words, Proxy #1 needs to police if UA #1 does not attempt to use a different codec that requires more bandwidth. After all, Proxy #1 will require disclosure of all the message body by setting no Warning header requiring Content-Type. + [If the above is supposed to be just an example, it sounds + rather normative. If it really is part of the spec, why does + this spec mandate codec policing?] =20 If Proxy #1 succeeds in this decryption, it MAY inspect the "unprotectedAttrs" field of the CMS EnvelopedData body. If the @@ -710,11 +713,11 @@ a 403 (Forbidden) response if the message is a request, otherwise any existing dialog MAY be terminated. =20 - When Proxy #1 needs validate the data integrity of the content but + When Proxy #1 needs to validate the data integrity of the content but the indicated body does not contain CMS SignedData body, Proxy #1 MUST respond with a 495 (Signature Required) response if the message is a request, otherwise any existing dialog MAY be terminated. A 495 - response contain no Warning header requiring Content-Type to be + response contains no Warning header requiring Content-Type to be attached a signature, since the signature of the whole body is always required, when the data integrity is required. =20 @@ -730,12 +733,12 @@ =20 =20 to decrypt the CMS EnvelopedData. If the decryption fails, Proxy #1 - MUST respond with 496 (Proxy Indecipherable) that contains its own + MUST respond with a 496 (Proxy Indecipherable) response that contains its own public key and no Warning header requiring a specific Content-Type. After getting decipherable data, Proxy #1 inspects the content and - validate the signature, if it exists. If the signature for the whole - body does not exist, Proxy #1 MUST respond with 495 (Signature - Required) that contains no Warning header requiring a specific + validates the signature, if it exists. If the signature for the whole + body does not exist, Proxy #1 MUST respond with a 495 (Signature + Required) response that contains no Warning header requiring a specific Content-Type. If the encrypted data is attached with the signature outside, Proxy #1 MAY first validate the signature, instead of checking the existence of the signature inside. @@ -745,7 +748,7 @@ =20 When a provider operating Proxy #1 does not allow any information related to its security policies to be revealed to Proxy #2 - serving UA #2, Proxy #1 MAY deletes the "Proxy-Required-Body" + serving UA #2, Proxy #1 MAY delete the "Proxy-Required-Body" header. However, when UA #1 sends the request to Proxy #1 via a proxy server operated by another provider, there is no way to conceal the header from the other proxy servers. @@ -791,7 +794,7 @@ The "where" column gives the request and response types in which the header field can be used. The values in the "where" column are as follows: - * R: The header field may appear in requests + * R: The header field may appear in requests. * 100-699: A numeral range indicates response codes with which the header field can be used. The "proxy" column gives the operations a proxy may perform on the @@ -813,7 +816,7 @@ =20 In the following example, a UAC needs message content in a MESSAGE request to be confidential and it allows a proxy server to view the - message body. Even though the Content-Length has no digit, the + message body. Even though the Content-Length field has no numeric value, the appropriate length is to be set. In the example message below, the text with the box of asterisks ("*") is encrypted: =20 @@ -904,7 +907,7 @@ SIP/2.0 496 Proxy Indeciperable Warning: 380 ss1.atlanta.example.com "Required to view 'text/plain'" Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=3Dz9hG4bK74bf= 9 - ;received=3D192.0.2.101 + ;received=3D192.0.2.101 From: Alice ;tag=3D9fxced76sl To: Bob ;tag=3D8321234356 Call-ID: 3848276298220188511@atlanta.example.com @@ -995,7 +998,7 @@ ****************************************************************** =20 =20 - When the proxy server successfully views the SDP, and the UAS + When the proxy server successfully views the SDP, the UAS responds with a 200 OK. The 200 OK is to be encrypted as follows: =20 =20 @@ -1048,7 +1051,7 @@ =20 In the following example, a UA needs the integrity of message content in a MESSAGE request to be validated by a proxy server before it - views message content. Even though the Content-Length has no digit, + views message content. Even though the Content-Length field has no numerical value, the appropriate length is to be set. =20 =20 @@ -1099,7 +1102,7 @@ =20 =20 If the proxy server successfully validates the integrity of the - message body, the UAC normally receives a 200 OK from the UAS. + message body, the UAC receives a 200 OK from the UAS as normal. However, if a proxy server does not receive a signature for the whole message body, the UAC receives a 495 (Signature Required) error response from the proxy server, as follows: @@ -1127,7 +1130,7 @@ =20 SIP/2.0 495 Signature Required Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=3Dz9hG4bK74bf= 9 - ;received=3D192.0.2.101 + ;received=3D192.0.2.101 From: Alice ;tag=3D9fxced76sl To: Bob ;tag=3D8321234356 Call-ID: 3848276298220188511@atlanta.example.com @@ -1158,7 +1161,7 @@ to, or the domain where the recipients connect to. Additionally, a UA MUST verify the identifier of the proxy server and chains to a trusted certificate authority of the public key certificate. If a UA - fails to check the correspondence and/or the verification, the public + can't check the correspondence and/or the verification, the public key certificate is presumably replaced or forged by a malicious user. =20 8.2 Tampering with a Message Body @@ -1208,8 +1211,8 @@ 9. IANA Considerations =20 This document defines a new SIP header, "Proxy-Required-Body", of - which the syntax is shown in Section 6. This document also defines a - new SIP response-code, 495 "Signature Required", 496 "Proxy + which the syntax is shown in Section 6. This document also defines two + new SIP response-codes: 495 "Signature Required" and 496 "Proxy Indecipherable", and a new Warn-code, 380 "Required to view Content- Type", as described in Section 4. =20 -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 10 15:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHoHZ-0004Mg-2Y; Fri, 10 Mar 2006 15:32:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHoHY-0004MM-BY for sip@ietf.org; Fri, 10 Mar 2006 15:32:16 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHoHW-0002u6-Rw for sip@ietf.org; Fri, 10 Mar 2006 15:32:16 -0500 Received: (qmail 13231 invoked by uid 0); 10 Mar 2006 20:32:11 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 10 Mar 2006 20:32:11 -0000 Message-ID: <006801c64481$b3b7e080$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "IETF SIP List" References: <4410B214.30800@cisco.com> Subject: Re: [Sip] updated GRUU spec Date: Fri, 10 Mar 2006 21:32:08 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Jonathan, Nice to see this work progressing Some minor remarks: - section 7.1.1.1 : Contacts provided by the UA should probably also not contain the "gruu" URI parameter, as it should not be a GRUU - section 7.1.2.1 : should the REGISTER response contain a Supported or Require header? I suppose even if the UA is not requesting GRUUs, the registrar could still indicate support for them, such that the UA knows it can request them. So a suggestion might be: if REGISTER contains Supported: gruu, response MUST have Require, else it SHOULD have Supported - section 14.3 : This text still refers to Supported: gruu as the mechanism to indicate that Contact is a GRUU Regards, jeroen ----- Original Message ----- From: "Jonathan Rosenberg" To: "IETF SIP List" Sent: Thursday, March 09, 2006 11:54 PM Subject: [Sip] updated GRUU spec > I've submitted an update to the GRUU spec. Until it appears, you can pick > it up at: > > http://www.jdrosen.net/papers/draft-ietf-sip-gruu-07.txt > > There are some major changes in here. They are: > > * removal of the instance contact parameter definition, which now lives in > sip-outbound. I think this was a huge improvement because of this; gruu > works much better now with the dependencies reversed > > * elimination of the edge proxy record-route munging mess. In its place, > the home proxy will rewrite the r-uri of mid-dialog requests (which will > have the gruu) to equal the registered contact. This is simple to do, > eliminates the spiraling problem completely, and requires no complicated > procedures to detemrine when to apply it. UA's do not record-route. The > mechanism does not address HA and failover for mid-dialog requests (nor > does sip-outbound). We are pushing that off, since neither gruu nor > sip-outbound was targeted at meeting that as a requirement. This was the > conclusion a small group of us came to in some off-line discussions. > > * addition of a "gruu" URI parameter, to flag a URI as being a gruu. I > have argued against this a lot up till now. However, seems I was in the > minority so in part this reflects group consensus. When reviewing though > the handling of the opaque parameter, it turned out things really fell > apart in depending on supported as a clue to gruu-ness. Really the root > need here is that we have a backwards compatibility issue; it would > probably not have been necessary to have a 'gruu' uri param if the Contact > URI had the gruu property all along. But the fact that it doesnt is a big > driver here. Thus, 'gruu' is similar to 'lr' - both are URI flags meant to > address this backwards compatibility issue. > > * as a consequence of the point above, there is virtually no mention of > supported header field and its interactions with gruu > > * Removed requirement for inserting Require in 200 OK to REGISTER; a > UA doesnt HAVE to include gruu in contacts anymore (though its still > SHOULD) > > * removed bit about future specifications dealing with the fact that > mid-dialog requests never go e2e, but always through proxies. No one > is ever going to "fix" this. > > * gruu mechanism doesn't require the sip-outbound mechanisms to be USED > with gruu; there is a normative spec dependency, which is different. gruu > requires sip-outbound to be used ONLY if you are trying to register > multiple contacts to the same instance, for this redundancy feature > > > Assuming folks are happy with these changes, there are no open issues I'm > aware of. > > 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 From sip-bounces@ietf.org Fri Mar 10 17:49:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHqOM-0000hZ-UT; Fri, 10 Mar 2006 17:47:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHqOL-0000eT-8l for sip@ietf.org; Fri, 10 Mar 2006 17:47:25 -0500 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 1FHqOJ-0002hv-Tt for sip@ietf.org; Fri, 10 Mar 2006 17:47:25 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 10 Mar 2006 14:47:16 -0800 X-IronPort-AV: i="4.02,181,1139212800"; d="scan'208"; a="414553589:sNHT1004975232" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2AMlGw1021143 for ; Fri, 10 Mar 2006 14:47:16 -0800 (PST) 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.211); Fri, 10 Mar 2006 17:47:15 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Mar 2006 17:47:15 -0500 Message-ID: <441201F3.3040606@cisco.com> Date: Fri, 10 Mar 2006 17:47:15 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Cullen Jennings' (E-mail)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 22:47:15.0798 (UTC) FILETIME=[94259F60:01C64494] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: SIP IETF Subject: [Sip] Re: draft-ietf-sip-outbound-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 I only have a couple of comments re this revision: "5.1. Processing Register Requests When an Edge Proxy receives a registration request with a sip.instance media feature tag in the Contact header field, it MUST form a flow identifier token that is unique to this network flow. The Edge Proxy MUST insert this token into a URI referring to this proxy and place this URI into a Path header field as described in RFC 3327 [12]. The token MAY be placed in the userpart of the URI." I believe this should only be done if the request contains Supported:path. Without Supported:path it should not add a Path entry, and without that none of this works. "The advantage to a stateless approach to managing the flow information is that there is no state on the edge proxy that requires clean up or that has to be synchronized with the registrar." This isn't quite true. The flow itself is state. How long should it be kept around? Seems like deciding that requires *some* additional state. 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 Sat Mar 11 13:53:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI9BQ-00023v-HM; Sat, 11 Mar 2006 13:51:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI9BO-00023g-Vq for sip@ietf.org; Sat, 11 Mar 2006 13:51:18 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FI9BN-0006SN-Ct for sip@ietf.org; Sat, 11 Mar 2006 13:51:18 -0500 Received: (qmail 12740 invoked by uid 0); 11 Mar 2006 18:51:12 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 11 Mar 2006 18:51:12 -0000 Message-ID: <006b01c6453c$c351a560$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: References: Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-02.txt Date: Sat, 11 Mar 2006 19:51:10 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 this draft: Section 3.2 (and elsewhere): in addition to stating that a proxy/registrar should prefer the most recently registered flow, I would suggest that the registrar explicitly invalidates an existing registration when it receives a new registration with the same instance-id / reg-id. This situation would most likely be due to a reboot of the client. For TCP and other connection-oriented transports it would be detected, but a registration over UDP could survive a client crash Section 3.3: the example route set should include the 'lr' parameter in each URI, as is done in section 8 Section 3.5: the statement "[...] most operating systems do not allow the time to be set on a per connection basis." is not true. Although I must admist I have no personal programming experience on this, Linux seems to offer "3 non-standard TCP socket options for tweaking the keepalive behavior of individual sockets: TCP_KEEPIDLE, TCP_KEEPCNT, and TCP_KEEPINTVL. The values set on a socket with these options should override the system-wide default.[http://www.ussg.iu.edu/hypermail/linux/kernel/0508.2/0745.html]. Windows offers WSAIoctl with SIO_KEEPALIVE_VALS, which also provides per-connection setting of keep-alive (enable, time and interval) Section 4.1: When firmware is updated, should the instance-id be updated too? I've mentioned before that Jonathan made a remark on caching of UA capabilities some time ago, would there be other reasons to do this? Section 8: The second REGISTER request should have a different Via branch and From-tag (in addition to the Call-ID which is already different) Section 9: Perhaps the ABNF could be made more in line with the text, which states that "the instance-id MUST be an URN [RFC2141]". Suggestion to change it into instance-val = ; defined in RFC2141Regards,Jeroen >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-02.txt > Pages : 31 > Date : 2006-3-7 > > 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. > Even when a proxy server can open a TCP connection to a User Agent, > most User Agents lack a certificate suitable to act as a TLS > (Transport Layer Security) server. 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-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-outbound-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-outbound-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. > -------------------------------------------------------------------------------- > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 12 00:08:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIImJ-0006Jm-9j; Sun, 12 Mar 2006 00:06:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIImH-0006Gh-BT for sip@ietf.org; Sun, 12 Mar 2006 00:06:01 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIImG-0000fz-S4 for sip@ietf.org; Sun, 12 Mar 2006 00:06:01 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id k2C560VV172578 for ; Sun, 12 Mar 2006 05:06:00 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2C56OJF222026 for ; Sun, 12 Mar 2006 06:06:24 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k2C55x1G031003 for ; Sun, 12 Mar 2006 06:05:59 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k2C55x0p031000 for ; Sun, 12 Mar 2006 06:05:59 +0100 In-Reply-To: To: sip@ietf.org Subject: Re: [Sip] Case sensitivity of user name - why RFC 3261 is more strict then RFC 2543 [RESEND] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Sun, 12 Mar 2006 07:06:23 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/03/2006 07:06:24, Serialize complete at 12/03/2006 07:06:24 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: sip@ietf.org X-Mailman-Version: 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 email RFC does not specify if the user name in the email should be case sensitive or not but says that the case should be preserved in order to accommodate hosts where the user name is case sensitive. Current practice in email is that I can write the user name in what case I choose and it will reach to the user. So what is the current practice in SIP? Do implementations ignore RFC 3261? I also could not find anything about backward compatibility to RFC 2543 who says that user names are case insensitive. Thanks --Avshalom Avshalom Houri/Haifa/IBM@IBMIL 10/03/2006 12:49 PM To sip@ietf.org cc Subject [Sip] Case sensitivity of user name - why RFC 3261 is more strict then RFC 2543 [RESEND] Unless I am completely missing something I think that it is an important issue. RFC 3261 seem to imply that user name in SIP is case sensitive while email and even RFC 2543 do not impose this restriction. Unless implementations ignore RFC 3261 in this case there may be a usage issue. Most SIP implementations are connected to email systems and users are used to write the user name in a free way without regarding case. When a user put a name in e.g. a dialogue box for INVITE I am not sure that we can expect that the user will match the way that the other user will register in their proxy. Can someone clarify this issue? Below are excerpts from the relevant RFCs: RFC 2543 (section 2, page 24) allows for: SIP URLs are case-insensitive, so that for example the two URLs sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All URL parameters are included when comparing SIP URLs for equality. That is RFC 2543 does not care about the case of the user name. RFC 3261 says in section 19.14: SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) sip:alice@AtLanTa.CoM;Transport=UDP That is we are having a stricter rules for user name comparison. Does anyone remember why it was done? I could not find a reference to this in the list of changes from RFC 2543 at the end of RFC 3261. In email as far as I know user names are NOT case sensitive. RFC 821 only says: Commands and replies are not case sensitive. That is, a command or reply word may be upper case, lower case, or any mixture of upper and lower case. Note that this is not true of mailbox user names. For some hosts the user name is case sensitive, and SMTP implementations must take case to preserve the case of user names as they appear in mailbox arguments. Host names are not case sensitive. So for email servers need only to preserve the name casing. Thanks --Avshalom _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 12 09:58:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIRzS-0004af-GW; Sun, 12 Mar 2006 09:56:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIRzQ-0004YM-K1 for sip@ietf.org; Sun, 12 Mar 2006 09:56:12 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIRzP-0006wr-Bi for sip@ietf.org; Sun, 12 Mar 2006 09:56:12 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 12 Mar 2006 06:56:12 -0800 X-IronPort-AV: i="4.02,184,1139212800"; d="scan'208"; a="1784237525:sNHT28433572" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2CEuA1n002627 for ; Sun, 12 Mar 2006 06:56:10 -0800 (PST) Received: from 10.21.121.235 ([10.21.121.235]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 12 Mar 2006 14:56:10 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 12 Mar 2006 05:57:24 -0800 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Thread-Topic: Comments on draft-ietf-sip-connect-reuse-05.txt Thread-Index: AcZF3OOVIhEnGbHQEdq2/QARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Comments on draft-ietf-sip-connect-reuse-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 If a proxy hosts two domain one.example.com and two.example.com on the same IP and port, this does not seem to work. The wrong TLS connection would be used. The problem is the cache is populated with the IP/port as the index instead of using the cert name as the index. The Para Because an alias connection might be reclaimed during a transaction, clients SHOULD NOT enforce the RFC 3261 requirement of sending CANCEL and ACK (for non 2xx responses) to the same port. If the alias connection no longer exists, the client SHOULD open a new connection to the resolved address and send the CANCEL or ACK there instead. The newly opened connection MAY be inserted into the alias table. This scared me thought I can't put my finger on exactly why. It seems like it open opportunities for DDOS with amplification. I don't remember all the reasons that this text was in 3261 but I would to understood why this text was in 3261 and that it was ok to remove. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 12 13:13:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIV2O-0007MA-8E; Sun, 12 Mar 2006 13:11:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIV2M-0007Hj-Nz for sip@ietf.org; Sun, 12 Mar 2006 13:11:26 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIV2L-0005Ey-FO for sip@ietf.org; Sun, 12 Mar 2006 13:11:26 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 12 Mar 2006 10:11:26 -0800 X-IronPort-AV: i="4.02,185,1139212800"; d="scan'208"; a="1784251856:sNHT33334010" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2CIBO1l027634 for ; Sun, 12 Mar 2006 10:11:24 -0800 (PST) Received: from 10.21.121.235 ([10.21.121.235]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 12 Mar 2006 18:11:24 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 12 Mar 2006 10:11:25 -0800 From: Cullen Jennings To: Paul H Kyzivat Message-ID: Thread-Topic: draft-ietf-sip-outbound-02 Thread-Index: AcZGAF/tnp90grHzEdqjXwARJEEJ/A== In-Reply-To: <441201F3.3040606@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "sip@ietf.org" Subject: [Sip] Re: draft-ietf-sip-outbound-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 On 3/10/06 2:47 PM, "Paul Kyzivat" wrote: > I only have a couple of comments re this revision: > > "5.1. Processing Register Requests > > When an Edge Proxy receives a registration request with a > sip.instance media feature tag in the Contact header field, it MUST > form a flow identifier token that is unique to this network flow. > The Edge Proxy MUST insert this token into a URI referring to this > proxy and place this URI into a Path header field as described in RFC > 3327 [12]. The token MAY be placed in the userpart of the URI." > > I believe this should only be done if the request contains > Supported:path. Without Supported:path it should not add a Path entry, > and without that none of this works. Hmm, we probably need to fix some text here. I don't actually see how it matters if the UA supports the path header or not. It's the registrar that needs to support it. > > "The advantage to a stateless approach to managing the flow > information is that there is no state on the edge proxy that > requires clean up or that has to be synchronized with the > registrar." > > This isn't quite true. The flow itself is state. How long should it be > kept around? Seems like deciding that requires *some* additional state. > Agree - would it be better to phrase this as the state gets bound to the flow and lifetime is determined by the lifetime of the flow? I'm not sure how to say this. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 12 15:10:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIWru-0000rq-1K; Sun, 12 Mar 2006 15:08:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIWrs-0000ra-M7 for sip@ietf.org; Sun, 12 Mar 2006 15:08:44 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIWrs-0000lK-9V for sip@ietf.org; Sun, 12 Mar 2006 15:08:44 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 12 Mar 2006 12:08:43 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2CK8gw1016672; Sun, 12 Mar 2006 12:08:43 -0800 (PST) Received: from 10.21.121.235 ([10.21.121.235]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 12 Mar 2006 20:08:42 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 12 Mar 2006 12:08:43 -0800 Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING request processing? From: Cullen Jennings To: Hisham Khartabil , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING request processing? Thread-Index: AcZGEMLnAZKxbbIEEdqjXwARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 results don't look right to me. I can't really test very well on my notebook computer but with STUN on a apple powerbook I am getting 16,000 TPS at about 30% CPU. Who knows what I could get with an intel processor :-) Your results look like 6 to 10k TPS. When people quote ms I never have any clue if they are including the kernel time, it it is a latency or what. The number we need here is aggregate throughput, not latency so actual transactions per second on some suitable box might be the easies to compare. Similarly, the rates of OPTIONS also looked fairly slow so perhaps I just don't get what you are measuring. Ignoring that, when I look at the code, I can't see any particular reason that the speed of PING would not be roughly the same as STUN. The problem is this violates RFC 3261 in so many ways that you can barely make a list of them all. Once you do the processing to make this consistent with existing things, the performance will drop significantly - my guess is that it would drop to roughly the same rate as OPTION. On 3/6/06 10:02 AM, "Hisham Khartabil" wrote: > I promised to come back with hard real numbers on how long it will take > for a server to process and STUN request vs a SIP PING request > > Myth: processing a STUN request is 10 to 100 times faster than a SIP > PING request > > Assumptions: - SIP PING request is processed early in the stack and > bypasses any unnecessary validations. > - SIP PING response carries in the contact header the IP > address and port as appears in the IP packet (source IP and port). > > We implemented the PING request as described above in the reSIProcate > stack. Attached you will find the c++ file where the changes were made. > STUN was already implemented in the reSIProcate stack and used as is. > > Below you will see the findings: > > STUN request processing: 0.15 - 0.2 ms > SIP PING request processing: 0.1 - 0.2 ms > SIP OPTIONS request: 7 ms > SIP REGISTER request: 7 ms > > The measurement was taken between the time a request appeared on > ethereal and its response appearing on ethereal. Average was taken > manually. > > As you can see, SIP PING requests were sometimes faster to process that > STUN requests, but never slower. Actually the SIP PING requests on > average were faster to process. > > Myth Busted!!!! :) > > Regards, > Hisham > P.S. It took 15 mins to modify the sip stack to do the PING response. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 12 15:29:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIX9w-0008NA-Mb; Sun, 12 Mar 2006 15:27:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIX9u-0008Lz-UO for sip@ietf.org; Sun, 12 Mar 2006 15:27:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIX9t-0001GJ-KS for sip@ietf.org; Sun, 12 Mar 2006 15:27:22 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2006 12:27:23 -0800 X-IronPort-AV: i="4.02,185,1139212800"; d="scan'208"; a="261362647:sNHT31565940" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2CKRKYg001435 for ; Sun, 12 Mar 2006 12:27:20 -0800 (PST) Received: from 10.21.121.235 ([10.21.121.235]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 12 Mar 2006 20:27:20 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 12 Mar 2006 12:27:21 -0800 Subject: Re: [Sip] The Problem with PRACK From: Cullen Jennings To: Jonathan Rosenberg , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZGE11Im47npLIGEdqjXwARJEEJ/A== In-Reply-To: <440E5E52.20500@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 One of the difficult parts of PRACK has to do with fact that there are times when a UA can not sent a new set of SDP and has to wait until some current round completed then merge in all the SDP changes it wanted. I have not seen a single implementation that correctly implemented this. I imagine there are some correct implementation but the fact that there are so many wrong once suggests this is very hard to get right. The things that make PRACK hard may have to do with rigid limits on what can be correlated between an offer and answer in SDP. In finding a solution to PRACK, we might need to consider if we need slightly more powerful correlation facilities in SDP such that we can relax some of the current SIP level rules that make PRACK so hard. On 3/7/06 11:32 PM, "Jonathan Rosenberg" wrote: > At the last IETF, there was a lot of discussion and argument around > PRACK. The spark of this debate was the ICE specification, which had > words in it requiring the usage of PRACK and UPDATE in order to work > with early media. There was strong pushback from many implementors that > anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) > that showed the state machine in his implementation resulting from > PRACK, and it was not pretty. > > So, I'd like to discuss exactly what IS the problem with PRACK? There > are really two pieces of state machinery in play here. One piece is the > complication that PRACK introduces into the offer/answer model. With > PRACK, you can now get a final answer in the 18x, and then send a new > offer in UPDATE, or even in PRACK itself. Another piece is the state > machinery with the retransmissions itself - correlating the PRACK with a > particular reliable provisional response and causing it to stop. > > In a chat with Flemming today, he suggested in interested remedy to our > PRACK dilemma. Why not revise PRACK so that you can't send an offer or > answer with it; it has no impact on the set of allowed O/A exchanges > defined by RFC 3261. I'm not sure if that would consequently break the > preconditions mechanism, but maybe there are some kind of offer/answer > limitations that would simplify things. > > So, this is one idea. I'd like for people who have complained about > PRACK implementations to speak up and indicate what exactly makes it so > complicated for them. > > Thanks, > 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 Sun Mar 12 15:30:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXB1-0001JS-Vq; Sun, 12 Mar 2006 15:28:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXB1-0001JH-6Q for sip@ietf.org; Sun, 12 Mar 2006 15:28:31 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIXAz-0001HS-Tp for sip@ietf.org; Sun, 12 Mar 2006 15:28:31 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2006 12:28:31 -0800 X-IronPort-AV: i="4.02,185,1139212800"; d="scan'208"; a="261362757:sNHT29862256" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2CKST1l024632; Sun, 12 Mar 2006 12:28:29 -0800 (PST) Received: from 10.21.121.235 ([10.21.121.235]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 12 Mar 2006 20:28:28 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 12 Mar 2006 12:28:29 -0800 Subject: Re: [Sip] The Problem with PRACK From: Cullen Jennings To: Samir Srivastava , Paul H Kyzivat , Francois Audet Message-ID: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDKbTdkK7rzamkTDilDZQKBR4mhAAH2J5AALKbnt0= In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60AC93F68@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 SIPS does not imply TCP. For example SIPS can be sent over IPSEC protected connections. On 3/8/06 11:18 PM, "Samir Srivastava" wrote: > We can do for SIPS only. > > Thx > Samir > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, March 08, 2006 7:29 PM > To: Audet, Francois [SC100:3055:EXCH] > Cc: IETF SIP List > Subject: Re: [Sip] The Problem with PRACK > > > > Francois Audet wrote: >> I'm ok with the suggestion to deprecate using PRACK for Offer/Answer. >> >> While we are at it, why not go for deprecating the use PRACK >> altogether when TCP transport is used? > > Explain to me again how you would know that reliable transport is used > end to end? > > 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 Sun Mar 12 15:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXM7-0003Bi-Sn; Sun, 12 Mar 2006 15:39:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXM6-00039x-I8 for sip@ietf.org; Sun, 12 Mar 2006 15:39:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIXM4-0001YS-VP for sip@ietf.org; Sun, 12 Mar 2006 15:39:58 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2006 12:39:56 -0800 X-IronPort-AV: i="4.02,185,1139212800"; d="scan'208"; a="261363707:sNHT33186664" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2CKds1j026731; Sun, 12 Mar 2006 12:39:56 -0800 (PST) Received: from 10.21.121.235 ([10.21.121.235]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 12 Mar 2006 20:39:54 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 12 Mar 2006 12:39:54 -0800 Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-02.txt From: Cullen Jennings To: Jeroen van Bemmel , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-02.txt Thread-Index: AcZGFR4bXOM17rIIEdqjXwARJEEJ/A== In-Reply-To: <006b01c6453c$c351a560$31713b51@BEMBUSTER> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: 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 Many thanks for great comments. More inline... On 3/11/06 10:51 AM, "Jeroen van Bemmel" wrote: > Some comments on this draft: > > Section 3.2 (and elsewhere): in addition to stating that a proxy/registrar > should prefer the most recently registered flow, I would suggest that the > registrar explicitly invalidates an existing registration when it receives a > new registration with the same instance-id / reg-id. This situation would > most likely be due to a reboot of the client. For TCP and other > connection-oriented transports it would be detected, but a registration over > UDP could survive a client crash This has been a topic of large debate and we (with many but not most people saying exactly what you are saying). We asked about it in WG meeting and on list and came to agreement that the text that does not allow "explicit invalidation" was better. I'm scared to reopen this. > > Section 3.3: the example route set should include the 'lr' parameter in each > URI, as is done in section 8 thanks > > Section 3.5: the statement "[...] most operating systems do not allow the > time to be set on a per connection basis." is not true. Although I must > admist I have no personal programming experience on this, Linux seems to > offer "3 non-standard TCP socket options for tweaking the keepalive behavior > of individual sockets: TCP_KEEPIDLE, TCP_KEEPCNT, and TCP_KEEPINTVL. The > values set on a socket with these options should override the system-wide > default.[http://www.ussg.iu.edu/hypermail/linux/kernel/0508.2/0745.html]. > Windows offers WSAIoctl with SIO_KEEPALIVE_VALS, which also provides > per-connection setting of keep-alive (enable, time and interval) Wow - interesting. Long, Long ago when I wrote this, I went and looked in Windows 2k, Linux, and Solaris. I must has missed this. Thanks for finding this - I must have done a lousy job of looking. Have you done any testing to see if we can use this and avoid the whole STUN argument we have been having. > > Section 4.1: When firmware is updated, should the instance-id be updated > too? I've mentioned before that Jonathan made a remark on caching of UA > capabilities some time ago, would there be other reasons to do this? Good Questions - I would probably vote no but seems like a good discussion point. Things like B2BUA may have changing capabilities based on what is on the other side of them. Caching capabilities seems very risky. > > Section 8: The second REGISTER request should have a different Via branch > and From-tag (in addition to the Call-ID which is already different) Yes > > Section 9: Perhaps the ABNF could be made more in line with the text, which > states that "the instance-id MUST be an URN [RFC2141]". Suggestion to change > it into > instance-val = ; defined in RFC2141Regards,Jeroen Need to think about this but you are probably right. > > >> 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-02.txt >> Pages : 31 >> Date : 2006-3-7 >> >> 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. >> Even when a proxy server can open a TCP connection to a User Agent, >> most User Agents lack a certificate suitable to act as a TLS >> (Transport Layer Security) server. 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-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-outbound-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-outbound-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. >> > > > ------------------------------------------------------------------------------ > -- > > >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 12 15:57:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXbN-0000I9-8T; Sun, 12 Mar 2006 15:55:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXbL-0000GR-RJ for sip@ietf.org; Sun, 12 Mar 2006 15:55:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIXbK-00022A-Hj for sip@ietf.org; Sun, 12 Mar 2006 15:55:43 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2006 12:55:43 -0800 X-IronPort-AV: i="4.02,185,1139212800"; d="scan'208"; a="261364363:sNHT31852540" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2CKtf1j028957; Sun, 12 Mar 2006 12:55:41 -0800 (PST) Received: from 10.21.121.235 ([10.21.121.235]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 12 Mar 2006 20:55:40 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 12 Mar 2006 12:55:41 -0800 Subject: Re: [Sip] status on the SIP MIB modules? From: Cullen Jennings To: Jean-Francois Mule , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] status on the SIP MIB modules? Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Romascanu, Dan \(Dan\)" , klingle@cisco.com, Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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 updating. What do you think we need to do with this draft before we IESG should look at it again? Is it all done? On 3/6/06 8:56 AM, "Jean-Francois Mule" wrote: > > We submitted an update to the SIP MIB draft. > > It addresses the comments we received from the Dan and Juergen of the > mib doctors and various nits. The list of changes includes: > o removal of SipMethodIdentifier textual convention per MIB doctor > feedback > o updates of normative references (e.g. RFC 3291 --> RFC 4001) > o added a new section to provide a citation to IMPORTed RFCs as they > are norm. references > > We checked the ID text with IDnits (passes clean, no more long lines) > and the SMI definitions with SMICng (passes with no errors with the > recommended strict options at > http://ops.ietf.org/mib-review-tools.html). > > Kevin and Jean-Francois. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 12 16:02:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXgI-0005nY-L3; Sun, 12 Mar 2006 16:00:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIXgF-0005ko-PE for sip@ietf.org; Sun, 12 Mar 2006 16:00:47 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIXgE-0002Dw-G3 for sip@ietf.org; Sun, 12 Mar 2006 16:00:47 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 12 Mar 2006 13:00:47 -0800 X-IronPort-AV: i="4.02,185,1139212800"; d="scan'208"; a="1784269692:sNHT34585032" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2CL0jYg006160; Sun, 12 Mar 2006 13:00:45 -0800 (PST) Received: from 10.21.121.235 ([10.21.121.235]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 12 Mar 2006 21:00:45 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 12 Mar 2006 13:00:46 -0800 Subject: Re: [Sip] Followup on WGLC for draft-ietf-sip-e2m-sec-01.txt From: Cullen Jennings To: Dean Willis , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Followup on WGLC for draft-ietf-sip-e2m-sec-01.txt Thread-Index: AcZGGAhbRvH4RLILEdqjXwARJEEJ/A== In-Reply-To: <2B289687-CFA6-4461-9C54-58411D877F7E@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 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 3/9/06 1:32 PM, "Dean Willis" wrote: > > On Dec 16, 2005, at 1:36 PM, Dean Willis wrote: > >> >> Just so you folks don't think they're nothing to keep you busy over >> the holidays, I'd like to start working group last call of the End >> to Middle draft: >> >> http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-01.txt >> >> I'd also like to request additional-cross area review from the >> Security area on this document. >> >> Given the cross-area review, I'd like to conclude the WGLC by >> January 20, 2006. >> > > > Okay, kids. I haven't seen a single response to this WGLC, and Kumiko > tells me she hasn't either. This means one of several things: > > 1) You ate so much over the holidays that you forgot all about it. > > 2) The draft is perfect and ready to send to the IETF. > > 3) We just haven't thought about it enough to have an opinion. > > 4) We're waiting on the security review before we form our own > opinion because security is complicated and scary and the > practitioners have interesting hair. > > 5) You replied, but a GRUU ate your email. > > So which is it? > > -- Uh, for me 1,3, and 4. Perhaps at this meeting we could ask for a group of people to provide careful review. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 12 16:52:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIYST-00057M-GW; Sun, 12 Mar 2006 16:50:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIYSS-00057H-5K for sip@ietf.org; Sun, 12 Mar 2006 16:50:36 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIYSP-0003cl-Of for sip@ietf.org; Sun, 12 Mar 2006 16:50:36 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 12 Mar 2006 13:50:33 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2CLoWGv027503; Sun, 12 Mar 2006 13:50:32 -0800 (PST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 12 Mar 2006 16:50:32 -0500 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] status on the SIP MIB modules? Date: Sun, 12 Mar 2006 16:50:10 -0500 Message-ID: <0DEB933345E95A4083C4403CD2E7980C0163C366@xmb-rtp-211.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] status on the SIP MIB modules? Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDA From: "Kevin Lingle \(klingle\)" To: "Cullen Jennings \(fluffy\)" , "Jean-Francois Mule" , X-OriginalArrivalTime: 12 Mar 2006 21:50:32.0283 (UTC) FILETIME=[FC51F2B0:01C6461E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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 think anything else is needed. with this revision, we were adjusting=20 one aspect of the mib based on mib doctor comments. i very much hope this will be the last and the mib can proceed as-is. kevin -----Original Message----- From: Cullen Jennings (fluffy)=20 Sent: Sunday, March 12, 2006 3:56 PM To: Jean-Francois Mule; sip@ietf.org Cc: Romascanu, Dan (Dan); Kevin Lingle (klingle); Juergen Schoenwaelder Subject: Re: [Sip] status on the SIP MIB modules? Thanks for updating. What do you think we need to do with this draft before we IESG should look at it again? Is it all done? On 3/6/06 8:56 AM, "Jean-Francois Mule" wrote: >=20 > We submitted an update to the SIP MIB draft. >=20 > It addresses the comments we received from the Dan and Juergen of=20 > the mib doctors and various nits. The list of changes includes: > o removal of SipMethodIdentifier textual convention per MIB doctor > feedback > o updates of normative references (e.g. RFC 3291 --> RFC 4001) > o added a new section to provide a citation to IMPORTed RFCs as they > are norm. references >=20 > We checked the ID text with IDnits (passes clean, no more long lines)=20 > and the SMI definitions with SMICng (passes with no errors with the=20 > recommended strict options at=20 > http://ops.ietf.org/mib-review-tools.html). >=20 > Kevin and Jean-Francois. >=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 Sun Mar 12 17:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIZ1i-0001lI-1n; Sun, 12 Mar 2006 17:27:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIZ1f-0001fs-Uw for sip@ietf.org; Sun, 12 Mar 2006 17:26:59 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIZ1e-0004Xj-Ku for sip@ietf.org; Sun, 12 Mar 2006 17:26:59 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 Mar 2006 17:26:58 -0500 X-IronPort-AV: i="4.02,185,1139202000"; d="scan'208"; a="83967254:sNHT30661500" 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 k2CMQwWc013452 for ; Sun, 12 Mar 2006 17:26:58 -0500 (EST) 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.211); Sun, 12 Mar 2006 17:26:58 -0500 Received: from [10.86.242.255] ([10.86.242.255]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 12 Mar 2006 17:26:57 -0500 Message-ID: <4414A030.1000003@cisco.com> Date: Sun, 12 Mar 2006 17:26:56 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2006 22:26:57.0164 (UTC) FILETIME=[129C54C0:01C64624] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "sip@ietf.org" Subject: [Sip] Re: draft-ietf-sip-outbound-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 Cullen Jennings wrote: > On 3/10/06 2:47 PM, "Paul Kyzivat" wrote: > > >>I only have a couple of comments re this revision: >> >> "5.1. Processing Register Requests >> >> When an Edge Proxy receives a registration request with a >> sip.instance media feature tag in the Contact header field, it MUST >> form a flow identifier token that is unique to this network flow. >> The Edge Proxy MUST insert this token into a URI referring to this >> proxy and place this URI into a Path header field as described in RFC >> 3327 [12]. The token MAY be placed in the userpart of the URI." >> >>I believe this should only be done if the request contains >>Supported:path. Without Supported:path it should not add a Path entry, >>and without that none of this works. > > Hmm, we probably need to fix some text here. I don't actually see how it > matters if the UA supports the path header or not. It's the registrar that > needs to support it. The way that Path is specified, the UAC is supposed to indicate support before the proxies use it. Technically, things could still work fine without the UAC being complicit, but this is a constraint in the RFC. >> "The advantage to a stateless approach to managing the flow >> information is that there is no state on the edge proxy that >> requires clean up or that has to be synchronized with the >> registrar." >> >>This isn't quite true. The flow itself is state. How long should it be >>kept around? Seems like deciding that requires *some* additional state. >> > > Agree - would it be better to phrase this as the state gets bound to the > flow and lifetime is determined by the lifetime of the flow? I'm not sure > how to say this. Yeah, I'm not sure either. I was just reacting to the wording here, which seems misleading. Its not entirely clear to me what is the minimum amount of state that must be kept to make this work. There are probably alternatives depending on which particular pieces of state one might prefer to keep. One possibility is to keep the expiration time of the registration that the flow is associated with. 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 Sun Mar 12 18:02:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIZXx-0001Yd-3Z; Sun, 12 Mar 2006 18:00:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIZXv-0001PU-0V for sip@ietf.org; Sun, 12 Mar 2006 18:00:19 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIZXu-0006GK-Ic for sip@ietf.org; Sun, 12 Mar 2006 18:00:18 -0500 Received: (qmail 31863 invoked by uid 0); 12 Mar 2006 23:00:08 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 12 Mar 2006 23:00:08 -0000 Message-ID: <02f001c64628$b3385f10$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" , "Dean Willis" , References: Subject: Re: [Sip] Followup on WGLC for draft-ietf-sip-e2m-sec-01.txt Date: Mon, 13 Mar 2006 00:00:04 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 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 remark on consistency across drafts: Both http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-02.txt and http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-01.txt are using content-id to refer to a body contained in the same request. However, their ABNF is very different: Proxy-Required-Body = "Proxy-Required-Body" HCOLON required-proxy SEMI target-body required-proxy = host target-body = cid-param *(COMMA cid-param) cid-param = "cid" EQUAL content-id content-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT dot-atom = atom *( "." atom ) atom = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "'" / "`" / "~" )versus Location = "Location" HCOLON Location-value *(COMMA Location-value) location-value = (addr-spec / option-tag / token) addr-spec = cid-url / absoluteURI option-tag = string token = token / quoted-string cid-url = "cid" ":" content-id / absoluteURI = SIP or SIPS-URI content-id = url-addr-spec url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec(I sent a private comment to the authors proposing to change the latter into Location = "Location" HCOLON ( status-token / (locationURI *(COMMA locationURI)))status-token = "Unknown" / tokenlocationURI = SIP-URI / SIPS-URI / absoluteURI / cidURIcidURI = "cid:" content-idcontent-id = addr-spec ; URL encoding of RFC3261 addr-spec)In any case, these things look very similar - should we agree on a common syntax at least for the content-id part? Regards, Jeroen > On 3/9/06 1:32 PM, "Dean Willis" wrote: > >> >> On Dec 16, 2005, at 1:36 PM, Dean Willis wrote: >> >>> >>> Just so you folks don't think they're nothing to keep you busy over >>> the holidays, I'd like to start working group last call of the End >>> to Middle draft: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-01.txt >>> >>> I'd also like to request additional-cross area review from the >>> Security area on this document. >>> >>> Given the cross-area review, I'd like to conclude the WGLC by >>> January 20, 2006. >>> >> >> >> Okay, kids. I haven't seen a single response to this WGLC, and Kumiko >> tells me she hasn't either. This means one of several things: >> >> 1) You ate so much over the holidays that you forgot all about it. >> >> 2) The draft is perfect and ready to send to the IETF. >> >> 3) We just haven't thought about it enough to have an opinion. >> >> 4) We're waiting on the security review before we form our own >> opinion because security is complicated and scary and the >> practitioners have interesting hair. >> >> 5) You replied, but a GRUU ate your email. >> >> So which is it? >> >> -- > > Uh, for me 1,3, and 4. > > Perhaps at this meeting we could ask for a group of people to provide > careful review. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 12 18:29:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIZyJ-0005yH-9o; Sun, 12 Mar 2006 18:27:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIZyH-0005y0-Ip for sip@ietf.org; Sun, 12 Mar 2006 18:27:33 -0500 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIZyH-0006wn-7k for sip@ietf.org; Sun, 12 Mar 2006 18:27:33 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Mar 2006 17:27:32 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 12 Mar 2006 17:27:32 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Mar 2006 17:27:31 -0600 Message-ID: From: "Thomson, Martin" To: "Jeroen van Bemmel" , "Cullen Jennings" , "Dean Willis" , Date: Sun, 12 Mar 2006 17:27:31 -0600 Subject: RE: [Sip] Followup on WGLC for draft-ietf-sip-e2m-sec-01.txt MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Mar 2006 23:27:31.0731 (UTC) FILETIME=[88FB3E30:01C6462C] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Sip] Followup on WGLC for draft-ietf-sip-e2m-sec-01.txt Thread-Index: AcZGKOmVtexvOYxaTIC3sP0Q1TkZPAAAVPoA X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Allison Mankin X-BeenThere: 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="===============0556580191==" Errors-To: sip-bounces@ietf.org --===============0556580191== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message R29vZCBjb21tZW50Lg0KDQpBIGdlbmVyaWMgVVJJIHNob3VsZCBiZSBzdWZmaWNpZW50IGZvciAi TG9jYXRpb24iIChzZWUgUkZDIDIzOTIpLiAgSW4gd2hpY2ggY2FzZSwgdGhlIGxpbmUgdGhhdCB5 b3UgcHJvcG9zZToNCg0KICBsb2NhdGlvblVSSSA9ICBTSVAtVVJJIC8gU0lQUy1VUkkgLyBhYnNv bHV0ZVVSSSAvIGNpZFVSSQ0KDQouLi5jYW4gYmUgcmVkdWNlZCB0bzoNCg0KICBsb2NhdGlvblVS SSA9ICBhYnNvbHV0ZVVSSSA7IGMuZi4gUkZDIDQ5ODYNCg0KLi4uYnkgdmlydHVlIG9mIFNJUC1V UkksIFNJUFMtVVJJIGFuZCBjaWRVUkkgYmVpbmcgc3Vic2V0cyBvZiBhYnNvbHV0ZVVSSS4NCg0K VGhlIHJlcXVpcmVtZW50IGZvciAiUHJveHktUmVxdWlyZWQtQm9keSIgaXMgZGlmZmVyZW50LiAg SW4gdGhpcyBjYXNlIG9ubHkgY29udGVudC1JRCBpcyBwZXJtaXR0ZWQgKG9yIHVzZWZ1bCkuICBU aGUgZm9ybSBzdWdnZXN0ZWQgaXMgYWxtb3N0IGNvbnNpc3RlbnQgd2l0aCBwYXJhbWV0ZXJzIGlu IFJGQyAyMzg3Og0KDQogICBDb250ZW50LVR5cGU6IE11bHRpcGFydC9SZWxhdGVkOyBib3VuZGFy eT1leGFtcGxlLTI7DQogICAgICAgICAgICAgc3RhcnQ9Ijw5NTAxMTguQUVCSEBYSXNvbi5jb20+ Ig0KICAgICAgICAgICAgIHR5cGU9IlRleHQveC1Pa2llIg0KDQogICBQcm94eS1SZXF1aXJlZC1C b2R5OiBzczEuYXRsYW50YS5leGFtcGxlLmNvbTsNCiAgICAgICAgICAgICAgICAgICAgICAgIGNp ZD0xMjM0QGF0bGFudGEuZXhhbXBsZS5jb20NCg0KUGVyc29uYWxseSwgSSB3b3VsZCBwcmVmZXIg YSBjaWQ6IFVSSSBmb3IgdGhpcyBwYXJhbWV0ZXIgYXMgd2VsbC4gDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmVyb2VuIHZhbiBCZW1tZWwgW21haWx0bzpqYmVtbWVs QHpvbm5ldC5ubF0NCj4gU2VudDogTW9uZGF5LCAxMyBNYXJjaCAyMDA2IDEwOjAwIEFNDQo+IFRv OiBDdWxsZW4gSmVubmluZ3M7IERlYW4gV2lsbGlzOyBzaXBAaWV0Zi5vcmcNCj4gQ2M6IEFsbGlz b24gTWFua2luDQo+IFN1YmplY3Q6IFJlOiBbU2lwXSBGb2xsb3d1cCBvbiBXR0xDIGZvciBkcmFm dC1pZXRmLXNpcC1lMm0tc2VjLTAxLnR4dA0KPiANCj4gQSByZW1hcmsgb24gY29uc2lzdGVuY3kg YWNyb3NzIGRyYWZ0czogQm90aA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi1jb252ZXlhbmNlLQ0KPiAwMi50eHQNCj4gYW5kIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lwLWUybS1zZWMt MDEudHh0IGFyZQ0KPiB1c2luZyBjb250ZW50LWlkIHRvIHJlZmVyIHRvIGEgYm9keSBjb250YWlu ZWQgaW4gdGhlIHNhbWUgcmVxdWVzdC4NCj4gSG93ZXZlciwNCj4gdGhlaXIgQUJORiBpcyB2ZXJ5 IGRpZmZlcmVudDoNCj4gDQo+IFByb3h5LVJlcXVpcmVkLUJvZHkgICA9ICJQcm94eS1SZXF1aXJl ZC1Cb2R5IiBIQ09MT04gcmVxdWlyZWQtcHJveHkNCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgU0VNSSB0YXJnZXQtYm9keQ0KPiAgICByZXF1aXJlZC1wcm94eSAgICAgICAgPSBob3N0DQo+ ICAgIHRhcmdldC1ib2R5ICAgICAgICAgICA9IGNpZC1wYXJhbSAqKENPTU1BIGNpZC1wYXJhbSkN Cj4gICAgY2lkLXBhcmFtICAgICAgICAgICAgID0gImNpZCIgRVFVQUwgY29udGVudC1pZA0KPiAg ICBjb250ZW50LWlkICAgICAgICAgICAgPSBMRFFVT1QgZG90LWF0b20gIkAiIChkb3QtYXRvbSAv IGhvc3QpIFJEUVVPVA0KPiAgICBkb3QtYXRvbSAgICAgICAgICAgICAgPSBhdG9tICooICIuIiBh dG9tICkNCj4gICAgYXRvbSAgICAgICAgICAgICAgICAgID0gMSooIGFscGhhbnVtIC8gIi0iIC8g IiEiIC8gIiUiIC8gIioiIC8NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIl8iIC8gIisi IC8gIiciIC8gImAiIC8gIn4iICAgKXZlcnN1cw0KPiANCj4gTG9jYXRpb24gICAgICAgICAgID0g ICJMb2NhdGlvbiIgSENPTE9OIExvY2F0aW9uLXZhbHVlICooQ09NTUENCj4gICAgICAgICAgICAg ICAgICAgICAgICAgIExvY2F0aW9uLXZhbHVlKQ0KPiAgICBsb2NhdGlvbi12YWx1ZSAgICAgPSAg KGFkZHItc3BlYyAvIG9wdGlvbi10YWcgLyB0b2tlbikNCj4gICAgYWRkci1zcGVjICAgICAgICAg ID0gIGNpZC11cmwgLyBhYnNvbHV0ZVVSSQ0KPiAgICBvcHRpb24tdGFnICAgICAgICAgPSAgc3Ry aW5nDQo+ICAgIHRva2VuICAgICAgICAgICAgICA9ICB0b2tlbiAvIHF1b3RlZC1zdHJpbmcNCj4g ICAgY2lkLXVybCAgICAgICAgICAgID0gICJjaWQiICI6IiBjb250ZW50LWlkIC8NCj4gICAgYWJz b2x1dGVVUkkgICAgICAgID0gIFNJUCBvciBTSVBTLVVSSQ0KPiAgICBjb250ZW50LWlkICAgICAg ICAgPSAgdXJsLWFkZHItc3BlYw0KPiAgICB1cmwtYWRkci1zcGVjICAgICAgPSAgYWRkci1zcGVj IDsgVVJMIGVuY29kaW5nIG9mIFJGQyA4MjIgYWRkci1zcGVjKEkNCj4gc2VudCBhIHByaXZhdGUg Y29tbWVudCB0byB0aGUgYXV0aG9ycyBwcm9wb3NpbmcgdG8gY2hhbmdlIHRoZSBsYXR0ZXIgaW50 bw0KPiBMb2NhdGlvbiAgICAgICAgICAgPSAgIkxvY2F0aW9uIiBIQ09MT04gKCBzdGF0dXMtdG9r ZW4gLyAobG9jYXRpb25VUkkNCj4gKihDT01NQSBsb2NhdGlvblVSSSkpKXN0YXR1cy10b2tlbiAg ICAgICA9ICAiVW5rbm93biIgLyB0b2tlbmxvY2F0aW9uVVJJDQo+ID0gIFNJUC1VUkkgLyBTSVBT LVVSSSAvIGFic29sdXRlVVJJIC8gY2lkVVJJY2lkVVJJICAgICAgICAgICAgID0gICJjaWQ6Ig0K PiBjb250ZW50LWlkY29udGVudC1pZCAgICAgICAgID0gIGFkZHItc3BlYyA7IFVSTCBlbmNvZGlu ZyBvZiBSRkMzMjYxDQo+IGFkZHItc3BlYylJbiBhbnkgY2FzZSwgdGhlc2UgdGhpbmdzIGxvb2sg dmVyeSBzaW1pbGFyIC0gc2hvdWxkIHdlIGFncmVlIG9uDQo+IGENCj4gY29tbW9uIHN5bnRheCBh dCBsZWFzdCBmb3IgdGhlIGNvbnRlbnQtaWQgcGFydD8NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBK ZXJvZW4NCj4gDQo+IA0KPiA+IE9uIDMvOS8wNiAxOjMyIFBNLCAiRGVhbiBXaWxsaXMiIDxkZWFu LndpbGxpc0Bzb2Z0YXJtb3IuY29tPiB3cm90ZToNCj4gPg0KPiA+Pg0KPiA+PiBPbiBEZWMgMTYs IDIwMDUsIGF0IDE6MzYgUE0sIERlYW4gV2lsbGlzIHdyb3RlOg0KPiA+Pg0KPiA+Pj4NCj4gPj4+ IEp1c3Qgc28geW91IGZvbGtzIGRvbid0IHRoaW5rIHRoZXkncmUgbm90aGluZyB0byBrZWVwIHlv dSBidXN5IG92ZXINCj4gPj4+IHRoZSBob2xpZGF5cywgSSdkIGxpa2UgdG8gc3RhcnQgd29ya2lu ZyBncm91cCBsYXN0IGNhbGwgb2YgdGhlIEVuZA0KPiA+Pj4gdG8gTWlkZGxlIGRyYWZ0Og0KPiA+ Pj4NCj4gPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt c2lwLWUybS1zZWMtMDEudHh0DQo+ID4+Pg0KPiA+Pj4gSSdkIGFsc28gbGlrZSB0byByZXF1ZXN0 IGFkZGl0aW9uYWwtY3Jvc3MgYXJlYSByZXZpZXcgZnJvbSB0aGUNCj4gPj4+IFNlY3VyaXR5IGFy ZWEgb24gdGhpcyBkb2N1bWVudC4NCj4gPj4+DQo+ID4+PiBHaXZlbiB0aGUgY3Jvc3MtYXJlYSBy ZXZpZXcsIEknZCBsaWtlIHRvIGNvbmNsdWRlIHRoZSBXR0xDIGJ5DQo+ID4+PiBKYW51YXJ5IDIw LCAyMDA2Lg0KPiA+Pj4NCj4gPj4NCj4gPj4NCj4gPj4gT2theSwga2lkcy4gSSBoYXZlbid0IHNl ZW4gYSBzaW5nbGUgcmVzcG9uc2UgdG8gdGhpcyBXR0xDLCBhbmQgS3VtaWtvDQo+ID4+IHRlbGxz IG1lIHNoZSBoYXNuJ3QgZWl0aGVyLiBUaGlzIG1lYW5zIG9uZSBvZiBzZXZlcmFsIHRoaW5nczoN Cj4gPj4NCj4gPj4gMSkgWW91IGF0ZSBzbyBtdWNoIG92ZXIgdGhlIGhvbGlkYXlzIHRoYXQgeW91 IGZvcmdvdCBhbGwgYWJvdXQgaXQuDQo+ID4+DQo+ID4+IDIpIFRoZSBkcmFmdCBpcyBwZXJmZWN0 IGFuZCByZWFkeSB0byBzZW5kIHRvIHRoZSBJRVRGLg0KPiA+Pg0KPiA+PiAzKSBXZSBqdXN0IGhh dmVuJ3QgdGhvdWdodCBhYm91dCBpdCBlbm91Z2ggdG8gaGF2ZSBhbiBvcGluaW9uLg0KPiA+Pg0K PiA+PiA0KSBXZSdyZSB3YWl0aW5nIG9uIHRoZSBzZWN1cml0eSByZXZpZXcgYmVmb3JlIHdlIGZv cm0gb3VyIG93bg0KPiA+PiBvcGluaW9uIGJlY2F1c2Ugc2VjdXJpdHkgaXMgY29tcGxpY2F0ZWQg YW5kIHNjYXJ5IGFuZCB0aGUNCj4gPj4gcHJhY3RpdGlvbmVycyBoYXZlIGludGVyZXN0aW5nIGhh aXIuDQo+ID4+DQo+ID4+IDUpIFlvdSByZXBsaWVkLCBidXQgYSBHUlVVIGF0ZSB5b3VyIGVtYWls Lg0KPiA+Pg0KPiA+PiBTbyB3aGljaCBpcyBpdD8NCj4gPj4NCj4gPj4gLS0NCj4gPg0KPiA+IFVo LCBmb3IgbWUgMSwzLCBhbmQgNC4NCj4gPg0KPiA+IFBlcmhhcHMgYXQgdGhpcyBtZWV0aW5nIHdl IGNvdWxkIGFzayBmb3IgYSBncm91cCBvZiBwZW9wbGUgdG8gcHJvdmlkZQ0KPiA+IGNhcmVmdWwg cmV2aWV3Lg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXANCj4gPiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBv ZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNCj4gPiBVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1 bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcA0KPiA+IFVzZSBzaXBwaW5nQGll dGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXANCj4gVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQ IFByb3RvY29sDQo+IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVl c3Rpb25zIG9uIGN1cnJlbnQgc2lwDQo+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2 ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVk IHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnks IG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQg ZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWls IGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClttZjJd --===============0556580191== 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 --===============0556580191==-- From sip-bounces@ietf.org Sun Mar 12 21:27:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIck9-00025N-F4; Sun, 12 Mar 2006 21:25:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIck8-00022G-Cl for sip@ietf.org; Sun, 12 Mar 2006 21:25:08 -0500 Received: from [219.141.250.5] (helo=mail) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIck4-0003MB-OX for sip@ietf.org; Sun, 12 Mar 2006 21:25:08 -0500 Received: from asechenshuping (ase_chenshuping.cecwireless.com.cn [10.2.4.140]) by mail.cecwireless.com.cn (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTPA id <0IW100756O0LIF@mail.cecwireless.com.cn> for sip@ietf.org; Mon, 13 Mar 2006 10:24:24 +0800 (CST) Date: Mon, 13 Mar 2006 10:24:55 +0800 From: Chen Shuping To: sip@ietf.org Message-id: <002701c64645$5185d190$8c04020a@cecwireless.com.cn> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZGRVEU/gSvI65iQlu9Hqd9qdYCEQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Sip] About add and remove steam X-BeenThere: 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="===============0582031442==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0582031442== Content-type: multipart/alternative; boundary="Boundary_(ID_M/o4ArXFrPK2gtnE4WxgcQ)" This is a multi-part message in MIME format. --Boundary_(ID_M/o4ArXFrPK2gtnE4WxgcQ) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi,All I want to know if there is a RFC or other spec to define how to add a stream to a session or remove existing steam from a session.such as user first establish an audio session,then he/she wants to add a video stream,or first add an audio and video session, then he/she wants to remove the video stream. My implementation is just send re-INVITE with sdp offer,if it is to add stream, i add a m= line and related attributes if it is to remove stream,I set the related port parameter of m= line to ZERO.I am not sure it is legal. --Boundary_(ID_M/o4ArXFrPK2gtnE4WxgcQ) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Hi,All
 
     I want to know if there is a RFC or other spec to define how to add a stream to a session or
 
 remove existing steam from a session.such as user first establish an audio session,then he/she wants
 
to add a video stream,or first add an audio and video session, then he/she wants to remove the video stream.
 
My implementation is just send re-INVITE with sdp offer,if it is to add stream, i add a m= line and related attributes
 
if it is to remove stream,I set the related port parameter of m= line to ZERO.I am not sure it is legal.
--Boundary_(ID_M/o4ArXFrPK2gtnE4WxgcQ)-- --===============0582031442== 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 --===============0582031442==-- From sip-bounces@ietf.org Mon Mar 13 03:43:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIicn-0005jD-V2; Mon, 13 Mar 2006 03:41:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIicl-0005j7-ON for sip@ietf.org; Mon, 13 Mar 2006 03:41:55 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIich-0005vp-4d for sip@ietf.org; Mon, 13 Mar 2006 03:41:52 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4FFEE4F001D; Mon, 13 Mar 2006 09:41:50 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 09:41:50 +0100 Received: from [136.225.183.102] ([136.225.183.102]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 09:41:47 +0100 From: "Christer Holmberg" To: "Chen Shuping" , sip@ietf.org Subject: Re: [Sip] About add and remove steam Date: Mon, 13 Mar 2006 10:36:57 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 13 Mar 2006 08:41:49.0912 (UTC) FILETIME=[F866ED80:01C64679] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, It IS legal. 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 Mon Mar 13 05:17:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIk5R-0000Uv-5w; Mon, 13 Mar 2006 05:15:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIk5P-0000Uq-Fk for sip@ietf.org; Mon, 13 Mar 2006 05:15:35 -0500 Received: from 207-170-229-131.gen.twtelecom.net ([207.170.229.131] helo=svr-wa-e2k1.usa.alliedtelesyn.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIk5O-0000Be-6l for sip@ietf.org; Mon, 13 Mar 2006 05:15:35 -0500 Received: from alliedtelesyn.com ([10.17.252.2]) by svr-wa-e2k1.usa.alliedtelesyn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 02:15:33 -0800 Received: from svr-mila-e2k1.eu.alliedtelesyn.com ([10.17.39.14] RDNS failed) by alliedtelesyn.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Mar 2006 11:06:19 +0100 Received: from svr-mila-fs3.eu.alliedtelesyn.com ([10.17.90.11]) by svr-mila-e2k1.eu.alliedtelesyn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 11:15:31 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 13 Mar 2006 11:15:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP codecs Thread-Index: AcZGhw80IwmJlYqESyS+29awqBEbVA== From: "Paradiso, Francesco" To: X-OriginalArrivalTime: 13 Mar 2006 10:15:31.0985 (UTC) FILETIME=[0F6B3010:01C64687] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Sip] SIP codecs X-BeenThere: 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="===============1576044753==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1576044753== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64687.0F376DEC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64687.0F376DEC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, if a UAC send an invite with codec "X" and "Y", it should be possible that a 200ok is received with codec "Z","X" and "Y" ? or the 200ok must be sent with a sub-set of supported codec? Is there an RFC that refer to this behaviour? =20 Thanks in advance and Best Regards Francesco=20 =20 ------_=_NextPart_001_01C64687.0F376DEC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
if a = UAC send an=20 invite with codec "X" and "Y", it should be possible that a 200ok is = received=20 with codec "Z","X" and "Y" ?
or the = 200ok must be=20 sent with a sub-set of supported codec?
Is = there an RFC that=20 refer to this behaviour?
 
Thanks = in advance=20 and Best Regards
Francesco 
 
------_=_NextPart_001_01C64687.0F376DEC-- --===============1576044753== 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 --===============1576044753==-- From sip-bounces@ietf.org Mon Mar 13 08:00:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FImdZ-0005WB-PY; Mon, 13 Mar 2006 07:59:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FImdY-0005Tq-3p for sip@ietf.org; Mon, 13 Mar 2006 07:59:00 -0500 Received: from uproxy.gmail.com ([66.249.92.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FImdW-0005Rg-QE for sip@ietf.org; Mon, 13 Mar 2006 07:59:00 -0500 Received: by uproxy.gmail.com with SMTP id u2so602655uge for ; Mon, 13 Mar 2006 04:58:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GtesCR9pIWywf8TFC1zJ/r2DOT97nFwGJoWT003fqqyWtVeWr1bxvWpwIWTUwocLNWaXlq9EJBsrTauzrugSXyhDWInRsmiDkhXqtBF0CHUFiGR1565AeekxVB8Cnz167zVCFIXsM/71lwkGkpTa6jbCvck9eUYE33Wsk/KeTuM= Received: by 10.66.225.19 with SMTP id x19mr2370046ugg; Mon, 13 Mar 2006 04:58:57 -0800 (PST) Received: by 10.67.19.16 with HTTP; Mon, 13 Mar 2006 04:58:57 -0800 (PST) Message-ID: Date: Mon, 13 Mar 2006 13:58:57 +0100 From: samuel To: "Paradiso, Francesco" Subject: Re: [Sip] SIP codecs In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 RFC 3264: "An Offer/Answer Model with the Session Description Protocol (SDP)" Samuel. 2006/3/13, Paradiso, Francesco : > > Hi all, > if a UAC send an invite with codec "X" and "Y", it should be possible tha= t a > 200ok is received with codec "Z","X" and "Y" ? > or the 200ok must be sent with a sub-set of supported codec? > Is there an RFC that refer to this behaviour? > > Thanks in advance and Best Regards > Francesco > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 13 09:52:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoNu-0002uk-Ip; Mon, 13 Mar 2006 09:50:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoNs-0002uf-U2 for sip@ietf.org; Mon, 13 Mar 2006 09:50:56 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIoNr-0000KI-KB for sip@ietf.org; Mon, 13 Mar 2006 09:50:56 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2DEorPF015919; Mon, 13 Mar 2006 08:50:53 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2DEorE21652; Mon, 13 Mar 2006 08:50:53 -0600 (CST) Message-ID: <441586CD.90502@lucent.com> Date: Mon, 13 Mar 2006 08:50:53 -0600 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: Cullen Jennings Subject: Re: [Sip] The Problem with PRACK References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae 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="===============1553593480==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1553593480== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030203090103030403090307" This is a cryptographically signed message in MIME format. --------------ms030203090103030403090307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > SIPS does not imply TCP. For example SIPS can be sent over IPSEC > protected connections. Cullen: I am curious -- Will it be valid to specify a sips URI over UDP if IPSec is employed beneath (i.e., don't use DTLS, but only upgrade the scheme to sips because of IPSec)? To me, the use of sips has been associated with a transport; i.e., rfc3261 probably assumes that a sips URI without a transport parameter applies to TCP only. Supporting sips over SCTP would mean inserting a "transport=sctp" parameter, and once DTLS becomes an RFC, one could also use "transport=udp". Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms030203090103030403090307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMTMxNDUwNTNaMCMGCSqGSIb3DQEJ BDEWBBSzL8KJQD94UVwqGbrihDQ52JDqiDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAZaoLgF2nW9FVLgKI2ZJ0zxhId9gIwFw2m1UmF+nZVp4wul7omKY4 6aj93uCGjJh5T0+iZ+d4xT4zExKNrHOIfiXKtPoCqqkPjAAAlq5x5Ek+HbeAkJDMpaPuWXGZ GMYm7ex6glMHpF2RyVESFUsv2LDaLspjLz1BbOtBRDP3o7MAAAAAAAA= --------------ms030203090103030403090307-- --===============1553593480== 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 --===============1553593480==-- From sip-bounces@ietf.org Mon Mar 13 11:16:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIpgy-00066l-Tn; Mon, 13 Mar 2006 11:14:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIpgx-00064h-4c for sip@ietf.org; Mon, 13 Mar 2006 11:14:43 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIpgv-0003QS-Pe for sip@ietf.org; Mon, 13 Mar 2006 11:14:43 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 13 Mar 2006 08:14:43 -0800 X-IronPort-AV: i="4.02,187,1139212800"; d="scan'208"; a="1784430008:sNHT31104584" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2DGEf1j008101; Mon, 13 Mar 2006 08:14:41 -0800 (PST) Received: from 10.21.88.69 ([10.21.88.69]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Mar 2006 16:14:40 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Mar 2006 08:14:40 -0800 Subject: Re: [Sip] The Problem with PRACK From: Cullen Jennings To: Cullen Jennings , Samir Srivastava , Paul H Kyzivat , Francois Audet Message-ID: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDKbTdkK7rzamkTDilDZQKBR4mhAAH2J5AALKbnt0AKW1Pug== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 It's been pointed to me that I was just plan wrong on the statement below. IPSEC is not allowed to be used for a SIPS URI when trying to reach the domain in the target. Sorry, Cullen On 3/12/06 12:28 PM, "Cullen Jennings" wrote: > > SIPS does not imply TCP. For example SIPS can be sent over IPSEC protected > connections. > > > On 3/8/06 11:18 PM, "Samir Srivastava" wrote: > >> We can do for SIPS only. >> >> Thx >> Samir >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, March 08, 2006 7:29 PM >> To: Audet, Francois [SC100:3055:EXCH] >> Cc: IETF SIP List >> Subject: Re: [Sip] The Problem with PRACK >> >> >> >> Francois Audet wrote: >>> I'm ok with the suggestion to deprecate using PRACK for Offer/Answer. >>> >>> While we are at it, why not go for deprecating the use PRACK >>> altogether when TCP transport is used? >> >> Explain to me again how you would know that reliable transport is used >> end to end? >> >> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 13 11:49:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqCj-0001Av-1d; Mon, 13 Mar 2006 11:47:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqCh-0001Aq-D2 for sip@ietf.org; Mon, 13 Mar 2006 11:47:31 -0500 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 1FIqCg-0004DC-1J for sip@ietf.org; Mon, 13 Mar 2006 11:47:31 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 13 Mar 2006 08:47:30 -0800 X-IronPort-AV: i="4.02,187,1139212800"; d="scan'208"; a="313723932:sNHT32816308" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2DGlT7T019133; Mon, 13 Mar 2006 08:47:29 -0800 (PST) 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.211); Mon, 13 Mar 2006 11:47:28 -0500 Received: from [192.168.1.101] ([10.86.242.194]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 11:47:28 -0500 Message-ID: <4415A220.6080101@cisco.com> Date: Mon, 13 Mar 2006 11:47:28 -0500 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: "Karthik Kamaraj - NPD, Chennai" Subject: Re: [Sip] updated GRUU spec References: <4B1D6623CCBD79489DE28D1CA062A47E01AF614D@npd-mail.hclt-ntl.co.in> In-Reply-To: <4B1D6623CCBD79489DE28D1CA062A47E01AF614D@npd-mail.hclt-ntl.co.in> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2006 16:47:28.0652 (UTC) FILETIME=[D071CCC0:01C646BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 header field is still supposed to be there, per rfc3261 on general usage of supported. I added a sentence to the section you cite making this clear. -Jonathan R. Karthik Kamaraj - NPD, Chennai wrote: > Hi Jonathan, > Though you have removed description regarding "Supported" header > with option tag "gruu" in section 8.1.1, the example call flow has > "Supported" header. If this header is present in the call flow, then I think > you have to add *a line* which describes this in the draft. > > Please correct me if I am wrong. > > Thanks, > Karthik > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Friday, March 10, 2006 4:24 AM > To: IETF SIP List > Subject: [Sip] updated GRUU spec > > > I've submitted an update to the GRUU spec. Until it appears, you can > pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-sip-gruu-07.txt > > There are some major changes in here. They are: > > * removal of the instance contact parameter definition, which now lives > in sip-outbound. I think this was a huge improvement because of this; > gruu works much better now with the dependencies reversed > > * elimination of the edge proxy record-route munging mess. In its place, > the home proxy will rewrite the r-uri of mid-dialog requests (which will > have the gruu) to equal the registered contact. This is simple to do, > eliminates the spiraling problem completely, and requires no complicated > procedures to detemrine when to apply it. UA's do not record-route. The > mechanism does not address HA and failover for mid-dialog requests (nor > does sip-outbound). We are pushing that off, since neither gruu nor > sip-outbound was targeted at meeting that as a requirement. This was the > conclusion a small group of us came to in some off-line discussions. > > * addition of a "gruu" URI parameter, to flag a URI as being a gruu. I > have argued against this a lot up till now. However, seems I was in the > minority so in part this reflects group consensus. When reviewing though > the handling of the opaque parameter, it turned out things really fell > apart in depending on supported as a clue to gruu-ness. Really the root > need here is that we have a backwards compatibility issue; it would > probably not have been necessary to have a 'gruu' uri param if the > Contact URI had the gruu property all along. But the fact that it doesnt > is a big driver here. Thus, 'gruu' is similar to 'lr' - both are URI > flags meant to address this backwards compatibility issue. > > * as a consequence of the point above, there is virtually no mention of > supported header field and its interactions with gruu > > * Removed requirement for inserting Require in 200 OK to REGISTER; a > UA doesnt HAVE to include gruu in contacts anymore (though its still > SHOULD) > > * removed bit about future specifications dealing with the fact that > mid-dialog requests never go e2e, but always through proxies. No one > is ever going to "fix" this. > > * gruu mechanism doesn't require the sip-outbound mechanisms to be USED > with gruu; there is a normative spec dependency, which is different. > gruu requires sip-outbound to be used ONLY if you are trying to register > multiple contacts to the same instance, for this redundancy feature > > > Assuming folks are happy with these changes, there are no open issues > I'm aware of. > > 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 Mon Mar 13 11:54:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqHf-0004BG-Fg; Mon, 13 Mar 2006 11:52:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqHd-0004AX-K8 for sip@ietf.org; Mon, 13 Mar 2006 11:52:37 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIqHd-0004RU-9z for sip@ietf.org; Mon, 13 Mar 2006 11:52:37 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 13 Mar 2006 08:52:38 -0800 X-IronPort-AV: i="4.02,187,1139212800"; d="scan'208"; a="1784450861:sNHT31371040" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2DGqZ1n024561; Mon, 13 Mar 2006 08:52:36 -0800 (PST) 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.211); Mon, 13 Mar 2006 11:52:35 -0500 Received: from [192.168.1.101] ([10.86.242.194]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 11:52:35 -0500 Message-ID: <4415A353.3080903@cisco.com> Date: Mon, 13 Mar 2006 11:52:35 -0500 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] updated GRUU spec References: <4410B214.30800@cisco.com> <006801c64481$b3b7e080$31713b51@BEMBUSTER> In-Reply-To: <006801c64481$b3b7e080$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2006 16:52:35.0379 (UTC) FILETIME=[8744A030:01C646BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Jeroen van Bemmel wrote: > Jonathan, > > Nice to see this work progressing > > Some minor remarks: > - section 7.1.1.1 : Contacts provided by the UA should probably also not > contain the "gruu" URI parameter, as it should not be a GRUU Ah, good comment. I had this restriction in the document, but then removed it. The reason is, it is actually possible to register a gruu from one domain to the registrar in another. Its weird, but would work. > - section 7.1.2.1 : should the REGISTER response contain a Supported or > Require header? No. The draft used to say that REGISTER response had to have Require, but no longer. Thats because we're not depending on the UA using the gruu to make the spiral prevention properly work. > > I suppose even if the UA is not requesting GRUUs, the registrar could still > indicate support for them, such that the UA knows it can request them. So a > suggestion might be: if REGISTER contains Supported: gruu, response MUST > have Require, else it SHOULD have Supported Require/Supported don't work that way. If a client puts Supported in a request, and the server needs the client to process the response, it puts Require. Supported is not placed in a response to indicate that a gruu was provided. Rather, the UA simply looks for the gruu parameter in the contact. > > - section 14.3 : This text still refers to Supported: gruu as the mechanism > to indicate that Contact is a GRUU Right, fixed. Now reads: gruu This option tag is used to identify the Globally Routable User Agent URI (GRUU) extension. When used in a Supported header, it indicates that a User Agent understands the extension. When used in a Require header field of a REGISTER request, it indicates that the registrar shouldn't process the registration unless it supports the GRUU extension. 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 Mon Mar 13 12:39:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqzS-00021J-5h; Mon, 13 Mar 2006 12:37:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqzQ-0001yq-2e for sip@ietf.org; Mon, 13 Mar 2006 12:37:52 -0500 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 1FIqzO-0006E2-Oz for sip@ietf.org; Mon, 13 Mar 2006 12:37:52 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 13 Mar 2006 09:37:50 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2DHbn1l015633; Mon, 13 Mar 2006 09:37:50 -0800 (PST) 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.211); Mon, 13 Mar 2006 12:37:49 -0500 Received: from [192.168.1.101] ([10.86.242.194]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 12:37:48 -0500 Message-ID: <4415ADEC.1060902@cisco.com> Date: Mon, 13 Mar 2006 12:37:48 -0500 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: Thomas.Levy@alcatel.fr References: <440F199F.2060007@alcatel.fr> <14203.12.151.41.2.1141859464.squirrel@12.151.41.2> <441137EF.50102@alcatel.fr> In-Reply-To: <441137EF.50102@alcatel.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2006 17:37:48.0737 (UTC) FILETIME=[D88E3310:01C646C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org Subject: [Sip] Re: Outbound and GRUU, X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thomas.Levy@alcatel.fr wrote: > Hi Rohan, > > You could still have multiple flows without using an instance id. I dont see how. You need a unique way to know that these are two flows to the same instance, and thus, you only need to use one of the two contacts that have been registered. -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 Mon Mar 13 13:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrXI-0002zg-Kw; Mon, 13 Mar 2006 13:12:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrXG-0002zT-GN for sip@ietf.org; Mon, 13 Mar 2006 13:12:50 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIrXF-0007a9-6P for sip@ietf.org; Mon, 13 Mar 2006 13:12:50 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2DID9uk007473 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 13 Mar 2006 12:13:10 -0600 In-Reply-To: <4414A030.1000003@cisco.com> References: <4414A030.1000003@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: draft-ietf-sip-outbound-02 Date: Mon, 13 Mar 2006 12:12:55 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Cullen Jennings , "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 Mar 12, 2006, at 4:26 PM, Paul Kyzivat wrote: >> Hmm, we probably need to fix some text here. I don't actually see >> how it >> matters if the UA supports the path header or not. It's the >> registrar that >> needs to support it. > > The way that Path is specified, the UAC is supposed to indicate > support before the proxies use it. Technically, things could still > work fine without the UAC being complicit, but this is a constraint > in the RFC. We added this behavior in PATH at the insistence of some security types. Others also viewed it as an OPES and/or UNSAF issue, which could perhaps explain just how confusing the whole proxy-routing model in SIP actually is. The idea behind Supported: path is that if the UA understands Path, then it has the ability to perform validation of received Path vectors to detect "unexpected proxies" that are presumed to be MITM attackers on its vector. It might also do run time analysis of Route and Via against Path to make sure everything is well-behaved. In practical reality, we seem to trust SIP proxies as implicitly as we trust IP routers, and expect routes to change periodically as topologies adapt. Of course, we can't re-route mid-dialog, meaning we just get a failure scenario for dialogs that are affected by a topology change unless subtle and complex (and unspecified by IETF) redundancy measures have been applied at the proxy layer. Also in practice, no UA that I know of pays any attention to the returned Path header field, and many systems are refusing to return it because they believe letting the UA know about the route of its requests violates the proxy-operator's veil of secrecy, which they hold to be a Good Thing. This lends credence to the argument that proxy-routing should be a single-layered special-case negotiated and controlled by the UAs (the "outbound" case) rather than the multi-layered, invisible to the UA service-invoking model that IMS uses. -- 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 Mar 13 13:28:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrl5-0005TW-0m; Mon, 13 Mar 2006 13:27:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrl3-0005TM-UD for sip@ietf.org; Mon, 13 Mar 2006 13:27:05 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIrl2-0008Da-K1 for sip@ietf.org; Mon, 13 Mar 2006 13:27:05 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2DIRPjk007565 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 13 Mar 2006 12:27:26 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BD57E6A-3067-488C-B6A9-5F4E66A60824@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Mon, 13 Mar 2006 12:27:10 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "sip@ietf.org" , Francois Audet , Paul H 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 On Mar 13, 2006, at 10:14 AM, Cullen Jennings wrote: > > It's been pointed to me that I was just plan wrong on the statement > below. > IPSEC is not allowed to be used for a SIPS URI when trying to reach > the > domain in the target. Right. But, SIPS is only required as far as the proxy serving the AOR. The AOR to Contact vector could be UDP/IPSEC, or even just plain unsecured UDP. This was established in 3261 at my insistence (over the objections of Jon, who hates it) because I had a use case with a SIPS AOR-serving proxy on the same LAN as my UDP-only SIP phone, and I wanted to be able to protect the "open internet" signaling path with sips. So, sips still doesn't assure you end-to-end TCP. Or security, for that matter. This also has implications for congestion control and the sending of large messages. You may recall a draft a few years ago that tried to establish assured end-to-end- transit using congestion-controlled links, so that we could send larger MESSAGE requests. The approach generated little traction, because people were thinking that SIP/UDP would be vastly more efficient than SIP/TCP, and the "wireless market" was dominating our discussion, and there was widespread superstition that TCP just wouldn't work in a wireless environment. Now we've realized that SIP requests themselves (not counting MESSAGE bodies) are starting to exceed the UDP single-packet limit. This, combined with the the advent of DTLS, better knowledge about TCP usage (people understand select/poll) and the broader acceptance in wireline applications might result in an opportunity to rethink some things here. Personally, I'm in favor of simply deprecating SIP/UDP (and forking, but I can't say that). -- 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 Mar 13 15:01:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FItCb-0005E2-Ip; Mon, 13 Mar 2006 14:59:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FItCa-0005Dw-2B for sip@ietf.org; Mon, 13 Mar 2006 14:59:36 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FItCY-0002cR-JA for sip@ietf.org; Mon, 13 Mar 2006 14:59:35 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2DJxW4D024988; Mon, 13 Mar 2006 13:59:32 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2DJxWE20748; Mon, 13 Mar 2006 13:59:32 -0600 (CST) Message-ID: <4415CF23.2070900@lucent.com> Date: Mon, 13 Mar 2006 13:59:31 -0600 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: Cullen Jennings Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 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="===============0124116583==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0124116583== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000701050904060803020000" This is a cryptographically signed message in MIME format. --------------ms000701050904060803020000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > If a proxy hosts two domain one.example.com and two.example.com on > the same IP and port, this does not seem to work. The wrong TLS > connection would be used. The problem is the cache is populated with > the IP/port as the index instead of using the cert name as the index. Cullen: To make sure I understand you, this is what *I think* you are talking about: Virtual Proxy (VP) P1 ---------\ | `--------- +--> one.example.com (VP1) ,--------- +--> two.example.net (VP2) P2 ---------/ | VP2 is able to use the existing alias to send requests to P1, an alias which was originally established between P1 and VP1 (not VP2). Is the charcterization of your concern accurate? If so, there are various ways to combat this: (1) VP could be made to maintain a separate alias table for all the virtual hosts it supports; (2) as you suggest, somehow use the cert in the indexing algorithm; (3) disable connection reuse for virtual SIP hosting. 1 seems to be the most appropriate, given that the VP will need to segregate the users belonging to each domain separately as well as the certs and other related logistics. I am curious: how many proxy servers today support virtual SIP hosting? > The Para Because an alias connection might be reclaimed during a > transaction, clients SHOULD NOT enforce the RFC 3261 requirement of > sending CANCEL and ACK (for non 2xx responses) to the same port. If > the alias connection no longer exists, the client SHOULD open a new > connection to the resolved address and send the CANCEL or ACK there > instead. The newly opened connection MAY be inserted into the alias > table. > > This scared me thought I can't put my finger on exactly why. It seems > like it open opportunities for DDOS with amplification. I don't > remember all the reasons that this text was in 3261 but I would to > understood why this text was in 3261 and that it was ok to remove. I think the paragraph you quote above is not worded quite correctly. All that is being said is something to capture the following case: P1 P2 ---------> INV succeeded and alias established .... <-------- re-INV over the existing alias; re-INV arrives successfully XXX Connection closed at P1 X<------ CANCEL goes out; dropped because connection closed at P1 <-------- Open a new connection to the resolved address to send the CANCEL This is the normal behavior in rfc3261; CANCELs and ACKs to non-2xx go to the same destination, but if the connection has been closed (for whatever reason), then the client will open a new connection. I will clarify this in the next revision. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms000701050904060803020000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMTMxOTU5MzFaMCMGCSqGSIb3DQEJ BDEWBBR4CJQxnnNo8viLMLIWn2p6KUfPDTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAHBp2Tic+17DD1XDvyKYgtqtt4s+lT8OUsEdrtMyHBWb+XsLBt/uI QvOrHl8DDA/yZm0uo43i22+J2OLEx7UPBIML8lMOUHOehFs11+Rs0j/Z5LMwRx+u/JkxylQa C9q+U0uHBzJmw17s9GKR4MNsexSjo30uIZcMc+8wUElG29MAAAAAAAA= --------------ms000701050904060803020000-- --===============0124116583== 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 --===============0124116583==-- From sip-bounces@ietf.org Mon Mar 13 16:22:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIuSz-00015H-E6; Mon, 13 Mar 2006 16:20:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIuSx-00015C-Or for sip@ietf.org; Mon, 13 Mar 2006 16:20:35 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIuSx-0005ru-EO for sip@ietf.org; Mon, 13 Mar 2006 16:20:35 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2DLKWX18293; Mon, 13 Mar 2006 16:20:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Mon, 13 Mar 2006 15:20:30 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AD91A19@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZEPX6gPa/vHUo8Qo253twk3wrA7ACoS+hQ From: "Samir Srivastava" To: "Aki Niemi" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 There is some marketing chant, as it raised the question of *using* . As we move from the islands of deployments to connected SIP deployments, SIP over TLS is more important. From user (Non Tech) prespective, If his calls are not secured end to end, he will not Like to do phone banking and other transactions / enrolling in the services etc, where his personal Data (SSN etc) are involved on our favourite VoIP User Agents. User gets a call (SIP/UDP), then They need to decide okay let us switch to secure mode, as we need to exchange identity stuff etc. As the call was earlier set, server impersonation might already happened and reInvites might not Offer the desired security. PSTN doesn't offer this user experience, but due to unsecure hop anywhere user is going to have some unpleasant experience of *switching over* or making a new call with security too bad. If SIPS is not used, reInvites in current situations doesn't help, where=20 we don't have end to end transport discovery mechanism. Sorry in our current situation call needs to be made again or use SIPS always at the first stage. Which makes the case of deprecating PRACK more strong. Moreover Unsecure SIP hops are another gold mines for Spammers. Let me draw a parallel, how many PCs one sees without virus protection. Either you buy secure managed service from the provider (This is very similar to SBC at the first hop i.e. B2BUA) or you take care of your PC yourself. Are we waiting for a spam simliar to "I Love You Virus" and keeping our SIP UA alerting (down) for a long as we move to "more connected" phase. I can still live with my PC down, but not without Phone connectivity, which is broken/less usable (SPAMS) because of *unsecurity* in VoIP. Then I still need PSTN.=20 Apart from security, as the development is going on PIDF large , SAML also large too. We might see 1300 size going up very quickly.=20 IMHO, IETF should first deprecate SIP over UDP. In the infancy days of SIP, I read a report SIP is so simple you can run over UDP, but in realization now it is causing more troubles then offering benefits. Thx Samir -----Original Message----- From: Aki Niemi [mailto:aki.niemi@nokia.com]=20 Sent: Friday, March 10, 2006 4:24 AM To: Srivastava, Samir [SC100:8826:EXCH] Cc: IETF SIP List Subject: Re: [Sip] The Problem with PRACK Inline. ext Samir Srivastava wrote: > ext Samir Srivastava wrote: >> It has been around 4 years. UA MUST have TCP. We need to draw a line=20 >> worrying about backward compatibility with 2543. UA is not 3261=20 >> compliant and should be fixed. If still it has only UDP, they will be >> few and we get gain for optimizing most of the UA supporting TCP. >=20 > Implementing and using are two completely different things.=20 >=20 > SS>> Agreed. Do you mean to say we are going to have *increasing*=20 > SS>> number > of UAs which will be=20 > ONLY supporting UDP in future, which have lot security holes=20 > because TLS is not used. I think (and hope) there will be an increasing number of UAs both supporting *and* using TCP and TLS in the future. > Even if the proxy wanted to use TCP for the last hop towards the UA,=20 > it won't be able to connect to a host behind a NAT. This is what=20 > sip-outbound is trying to fix. >=20 > SS>> How UDP is going to help here, if UA is not keeping the bindings > alive. UA needs to keep=20 > binding alive for every flow. Pl explain.=20 But if there is no contact registered for that UA that supports TCP, then the proxy is out of luck and can only downgrade to UDP. There's actually a wide range of associated problems with UAs I've used. For example, some might allow you to switch over to using TCP, but after that, the UA will only ever use TCP -- for registrations and invites alike -- leaving domains that only accept UDP unreachable. So again, implementing and using (let alone using wisely) are two entirely different things. Cheers, Aki Cheers, Aki >=20 > Cheers, > Aki >=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 Mar 13 17:16:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvJE-0000Tq-M9; Mon, 13 Mar 2006 17:14:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvJE-0000Tl-1W for sip@ietf.org; Mon, 13 Mar 2006 17:14:36 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIvJC-0007IK-OI for sip@ietf.org; Mon, 13 Mar 2006 17:14:35 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2DMETu29923; Mon, 13 Mar 2006 17:14:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Mon, 13 Mar 2006 16:14:28 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AD91B3C@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZGzAZOqoMwIt5nQ0iWS1ebe/R91AAHdt2A From: "Samir Srivastava" To: "Dean Willis" , "Cullen Jennings" X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, Paul H 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 =20 << Removed >> So, sips still doesn't assure you end-to-end TCP. Or security, for that matter. SS>> I think now I should start writing my first draft, for discovering end to end transport=20 (reliable, secure, unreliable) at UAS and indicating it back. It may find other use cases too. << Removed >> Personally, I'm in favor of simply deprecating SIP/UDP (and forking, but I can't say that). SS>> Atleast chairs agree on deprecating SIP over UDP. Nice !!=20 (B2BUA Bell headed, Deprecate Forking Idiots , nice terminology :-) Thx Samir -- 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 Mar 13 17:35:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvbR-00021c-NX; Mon, 13 Mar 2006 17:33:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvbP-00021X-QJ for sip@ietf.org; Mon, 13 Mar 2006 17:33:23 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIvbO-0007qd-JU for sip@ietf.org; Mon, 13 Mar 2006 17:33:23 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 481B06C022 for ; Mon, 13 Mar 2006 17:33:22 -0500 (EST) Subject: Re: [Sip] Determining if a call _can_ function From: "Dale R. Worley" To: Sip In-Reply-To: <20060306205006.GA25030@infointeractive.com> References: <20060306205006.GA25030@infointeractive.com> Content-Type: text/plain Date: Mon, 13 Mar 2006 17:33:22 -0500 Message-Id: <1142289202.4729.46.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 On Mon, 2006-03-06 at 16:50 -0400, David Benoit wrote: > This situation can be detected by Bob's UAS/UAC while processing the > INVITE. It can attempt to send a transaction to Alice's UAC and if any > response to that transaction is received, the call should be able to > continue without issue. > > Alice's UAC Bob's UAS/UAC > | | > |----- INVITE ---->| > |<------ 100 ------| > | X<--- PING ----| > | ECONNREFUSED ->| > |<------ 6XX ------| > |------- ACK ----->| I don't think this solves the problem in many cases like the one you are outlining. Because once Alice has a TCP connection set up, going out through whatever NAT-like arrangement is involved, Bob's attempt to send to Alice's TCP contact address works -- The PING is likely to take the reverse path of the INVITE, and thus get routed to the SIP agent which is the other end of the TCP connection that Alice has made. Pretty much line the response to the INVITE will be routed. So Bob's PING will be successful, but only because the TCP tunnel is open at that time. But neither Bob nor Alice has any good way of knowing that. I think the best available solution is for Alice's UAC to use a contact that it positively knows is globally routable, not only in regard to addressing, but also in regard to TCP vs. UDP issues. 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 Mar 13 19:08:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIx3g-0000IZ-2r; Mon, 13 Mar 2006 19:06:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIx3e-0000IU-Tm for sip@ietf.org; Mon, 13 Mar 2006 19:06:38 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIx3d-00036j-KD for sip@ietf.org; Mon, 13 Mar 2006 19:06:38 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2E06xvl008903 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 13 Mar 2006 18:07:00 -0600 In-Reply-To: <1142289202.4729.46.camel@cdhcp139.pingtel.com> References: <20060306205006.GA25030@infointeractive.com> <1142289202.4729.46.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6174FB58-1B39-463F-BC35-B0421F6DCAC7@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Determining if a call _can_ function Date: Mon, 13 Mar 2006 18:06:44 -0600 To: "Dale R. Worley" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 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 On Mar 13, 2006, at 4:33 PM, Dale R. Worley wrote: > I think the best available solution is for Alice's UAC to use a > contact > that it positively knows is globally routable, not only in regard to > addressing, but also in regard to TCP vs. UDP issues. Of course, the only way to be absolutely assured that a contact is globally routable is to exercise it from every node on the globe, using both TCP and UDP as you describe. That being rather unsassertable, we find ourselves in one of three real use cases: 1) A UA that knows its contact is NOT globally routable by inspection (aka, RFC 1918 or autoconfig ranges). 2) A UA that knows its contact is NOT globally routable by exercise -- it has STUNned a node, somewhere, that returns a different address from the one the UA believes itself to be using. 3) A UA that isn't sure. It knows that its contact MIGHT not be globally routable, but can't really prove it. So some point, we have to think about not global routability, but relative routability. Can this UA see that UA directly? If so, they can talk. if not, they need a helper node or nodes (STUN, TURN, or both) that can see both UAs, or a chain of helper nodes such that the each end of the chain is visible to one UA, and the intermediate nodes in the chain form a continuity path. This distinction doesn't mean a lot in our more conventional SIP deployments, but becomes quite significant in P2P-SIP work, where we might have two overlay networks, each running in autoconfig address space, but connected by a pair of relay agents. Something to think about. -- 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 Mar 13 20:29:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIyKR-0002oJ-ET; Mon, 13 Mar 2006 20:28:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIyKP-0002oE-Q3 for sip@ietf.org; Mon, 13 Mar 2006 20:28:01 -0500 Received: from [219.141.250.5] (helo=mail) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIyKK-0005Xc-03 for sip@ietf.org; Mon, 13 Mar 2006 20:28:01 -0500 Received: from asechenshuping (ase_chenshuping.cecwireless.com.cn [10.2.4.140]) by mail.cecwireless.com.cn (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTPA id <0IW30084YG1ATB@mail.cecwireless.com.cn> for sip@ietf.org; Tue, 14 Mar 2006 09:27:13 +0800 (CST) Date: Tue, 14 Mar 2006 09:27:44 +0800 From: Chen Shuping Subject: =?gb2312?B?tPC4tDogW1NpcF0gU0lQIGNvZGVjcw==?= In-reply-to: To: "'Paradiso, Francesco'" , sip@ietf.org Message-id: <002901c64706$7ec4cb40$8c04020a@cecwireless.com.cn> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZGhw80IwmJlYqESyS+29awqBEbVAAftHbw X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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="===============0175579651==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0175579651== Content-type: multipart/alternative; boundary="Boundary_(ID_Hl7atD68i+DLmX4YPFxYZQ)" This is a multi-part message in MIME format. --Boundary_(ID_Hl7atD68i+DLmX4YPFxYZQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Paradiso: =20 I think the answer in 200 OK for INVITE to the offer in INVITE method should take a sub-set according to RFC3264. =20 Because in one offer/answer round. If the answerer sends other codecs = which is not inidcated in offer,the answerer will not=20 =20 sure whether the UAC support the new codec(Actually, if the offer has no = Z in codec set,answerer should think ther offerer do not support =20 Z,so,the answerer can not include z in its codec set) _____ =20 =B7=A2=BC=FE=C8=CB: Paradiso, Francesco = [mailto:Francesco_Paradiso@alliedtelesyn.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA3=D4=C213=C8=D5 18:16 =CA=D5=BC=FE=C8=CB: sip@ietf.org =D6=F7=CC=E2: [Sip] SIP codecs Hi all, if a UAC send an invite with codec "X" and "Y", it should be possible = that a 200ok is received with codec "Z","X" and "Y" ? or the 200ok must be sent with a sub-set of supported codec? Is there an RFC that refer to this behaviour? =20 Thanks in advance and Best Regards Francesco=20 =20 --Boundary_(ID_Hl7atD68i+DLmX4YPFxYZQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Paradiso:
 
  I think the answer in 200 OK for INVITE = to the offer=20 in INVITE method should take a sub-set according to = RFC3264.
 
Because=20 in one offer/answer round. If the answerer sends other codecs which is = not=20 inidcated in offer,the answerer will not
 
sure=20 whether the UAC support the new codec(Actually, if the offer has no Z in = codec=20 set,answerer should think ther offerer do not = support
 
Z,so,the=20 answerer can not include z in its codec set)

=B7=A2=BC=FE=C8=CB: Paradiso, = Francesco=20 [mailto:Francesco_Paradiso@alliedtelesyn.com] =
=B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA3=D4=C213=C8=D5=20 18:16
=CA=D5=BC=FE=C8=CB: sip@ietf.org
=D6=F7=CC=E2: = [Sip] SIP=20 codecs

Hi=20 all,
if a = UAC send an=20 invite with codec "X" and "Y", it should be possible that a 200ok is = received=20 with codec "Z","X" and "Y" ?
or the = 200ok must be=20 sent with a sub-set of supported codec?
Is = there an RFC that=20 refer to this behaviour?
 
Thanks = in advance=20 and Best Regards
Francesco 
 
--Boundary_(ID_Hl7atD68i+DLmX4YPFxYZQ)-- --===============0175579651== 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 --===============0175579651==-- From sip-bounces@ietf.org Mon Mar 13 21:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIzHu-00017i-3E; Mon, 13 Mar 2006 21:29:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIzHs-00014C-CF for sip@ietf.org; Mon, 13 Mar 2006 21:29:28 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIzHr-0007nv-1W for sip@ietf.org; Mon, 13 Mar 2006 21:29:28 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 13 Mar 2006 21:29:27 -0500 X-IronPort-AV: i="4.02,188,1139202000"; d="scan'208"; a="84058020:sNHT31476624" 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 k2E2TOWc004696; Mon, 13 Mar 2006 21:29:24 -0500 (EST) 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.211); Mon, 13 Mar 2006 21:29:24 -0500 Received: from [192.168.1.101] ([10.86.242.194]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 21:29:23 -0500 Message-ID: <44162A83.5080508@cisco.com> Date: Mon, 13 Mar 2006 21:29:23 -0500 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: Chen Shuping Subject: Re: =?GB2312?B?tPC4tDogW1NpcF0gU0lQIGNvZGVjcw==?= References: <002901c64706$7ec4cb40$8c04020a@cecwireless.com.cn> In-Reply-To: <002901c64706$7ec4cb40$8c04020a@cecwireless.com.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Mar 2006 02:29:23.0985 (UTC) FILETIME=[1B9AD010:01C6470F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 This is not accurate. The answer may contain additional codecs. Note the following text in section 6 of rfc3264: For streams marked as sendrecv in the answer, the "m=" line MUST contain at least one codec the answerer is willing to both send and receive, from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). For streams marked as -Jonathan R. Chen Shuping wrote: > Paradiso: > > I think the answer in 200 OK for INVITE to the offer in INVITE method > should take a sub-set according to RFC3264. > > Because in one offer/answer round. If the answerer sends other codecs > which is not inidcated in offer,the answerer will not > > sure whether the UAC support the new codec(Actually, if the offer has no > Z in codec set,answerer should think ther offerer do not support > > Z,so,the answerer can not include z in its codec set) > > ------------------------------------------------------------------------ > *·¢¼þÈË:* Paradiso, Francesco [mailto:Francesco_Paradiso@alliedtelesyn.com] > *·¢ËÍʱ¼ä:* 2006Äê3ÔÂ13ÈÕ 18:16 > *ÊÕ¼þÈË:* sip@ietf.org > *Ö÷Ìâ:* [Sip] SIP codecs > > Hi all, > if a UAC send an invite with codec "X" and "Y", it should be possible > that a 200ok is received with codec "Z","X" and "Y" ? > or the 200ok must be sent with a sub-set of supported codec? > Is there an RFC that refer to this behaviour? > > Thanks in advance and Best Regards > Francesco > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Mon Mar 13 21:41:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIzRY-0005QB-0n; Mon, 13 Mar 2006 21:39:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIzRW-0005Q3-5Z for sip@ietf.org; Mon, 13 Mar 2006 21:39:26 -0500 Received: from [219.141.250.5] (helo=mail) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIzRU-0007x5-FT for sip@ietf.org; Mon, 13 Mar 2006 21:39:26 -0500 Received: from asechenshuping (ase_chenshuping.cecwireless.com.cn [10.2.4.140]) by mail.cecwireless.com.cn (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTPA id <0IW30082YJCJYX@mail.cecwireless.com.cn> for sip@ietf.org; Tue, 14 Mar 2006 10:38:46 +0800 (CST) Date: Tue, 14 Mar 2006 10:39:16 +0800 From: Chen Shuping Subject: =?gb2312?B?tPC4tDogtPC4tDogW1NpcF0gU0lQIGNvZGVjcw==?= In-reply-to: <44162A83.5080508@cisco.com> To: 'Jonathan Rosenberg' Message-id: <003c01c64710$7c95aab0$8c04020a@cecwireless.com.cn> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcZHDxY/6dFOhUoCT5aY2LrMcywsMAAAIZUg X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 If the answer could contain new codec(s) ,I think,it could not be listed = as the first one,usually the first codec will be prefered. I am not sure if the new codecs could be listed before the codecs = indicated in offer. Refer to the following section 5.1 in RFC3264 =20 In all cases, the formats in the "m=3D" line MUST be listed in order = of preference, with the first format listed being preferred. In this case, preferred means that the recipient of the offer SHOULD use the format with the highest preference that is acceptable to it. -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA3=D4=C214=C8=D5 10:29 =CA=D5=BC=FE=C8=CB: Chen Shuping =B3=AD=CB=CD: 'Paradiso, Francesco'; sip@ietf.org =D6=F7=CC=E2: Re: =B4=F0=B8=B4: [Sip] SIP codecs This is not accurate. The answer may contain additional codecs. Note the following text in section 6 of rfc3264: For streams marked as sendrecv in the answer, the "m=3D" line MUST contain at least one codec the answerer is = willing to both send and receive, from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). For streams marked as -Jonathan R. Chen Shuping wrote: > Paradiso: > =20 > I think the answer in 200 OK for INVITE to the offer in INVITE=20 > method should take a sub-set according to RFC3264. > =20 > Because in one offer/answer round. If the answerer sends other codecs=20 > which is not inidcated in offer,the answerer will not > =20 > sure whether the UAC support the new codec(Actually, if the offer has=20 > no Z in codec set,answerer should think ther offerer do not support > =20 > Z,so,the answerer can not include z in its codec set) >=20 > ---------------------------------------------------------------------- > -- > *=B7=A2=BC=FE=C8=CB:* Paradiso, Francesco=20 > [mailto:Francesco_Paradiso@alliedtelesyn.com] > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2006=C4=EA3=D4=C213=C8=D5 18:16 > *=CA=D5=BC=FE=C8=CB:* sip@ietf.org > *=D6=F7=CC=E2:* [Sip] SIP codecs >=20 > Hi all, > if a UAC send an invite with codec "X" and "Y", it should be possible=20 > that a 200ok is received with codec "Z","X" and "Y" ? > or the 200ok must be sent with a sub-set of supported codec? > Is there an RFC that refer to this behaviour? > =20 > Thanks in advance and Best Regards > Francesco > =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 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 Mar 14 00:18:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ1tC-0008OE-EN; Tue, 14 Mar 2006 00:16:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ1tA-0008O6-DS for sip@ietf.org; Tue, 14 Mar 2006 00:16:08 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ1t9-000422-3Q for sip@ietf.org; Tue, 14 Mar 2006 00:16:08 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id k2E5G2DU023628; Mon, 13 Mar 2006 22:16:03 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] status on the SIP MIB modules? Date: Mon, 13 Mar 2006 22:16:02 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] status on the SIP MIB modules? Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbA= From: "Jean-Francois Mule" To: "Kevin Lingle (klingle)" , "Cullen Jennings (fluffy)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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 with Kevin. Jean-Francois > -----Original Message----- > From: Kevin Lingle (klingle) [mailto:klingle@cisco.com] > Sent: Sunday, March 12, 2006 2:50 PM > To: Cullen Jennings (fluffy); Jean-Francois Mule; sip@ietf.org > Cc: Romascanu, Dan (Dan); Juergen Schoenwaelder > Subject: RE: [Sip] status on the SIP MIB modules? >=20 > i don't think anything else is needed. with this revision, we were > adjusting > one aspect of the mib based on mib doctor comments. i very much > hope > this > will be the last and the mib can proceed as-is. >=20 > kevin >=20 > -----Original Message----- > From: Cullen Jennings (fluffy) > Sent: Sunday, March 12, 2006 3:56 PM > To: Jean-Francois Mule; sip@ietf.org > Cc: Romascanu, Dan (Dan); Kevin Lingle (klingle); Juergen > Schoenwaelder > Subject: Re: [Sip] status on the SIP MIB modules? >=20 >=20 > Thanks for updating. What do you think we need to do with this draft > before we IESG should look at it again? Is it all done? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 01:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3Ay-0005FU-Hj; Tue, 14 Mar 2006 01:38:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3Ax-0005EW-9O for sip@ietf.org; Tue, 14 Mar 2006 01:38:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ38K-0006Ny-81 for sip@ietf.org; Tue, 14 Mar 2006 01:35:53 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Mar 2006 22:35:51 -0800 X-IronPort-AV: i="4.02,189,1139212800"; d="scan'208"; a="261663695:sNHT30120400" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2E6ZpYg009270; Mon, 13 Mar 2006 22:35:51 -0800 (PST) Received: from 10.21.83.107 ([10.21.83.107]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Mar 2006 06:35:51 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Mar 2006 22:35:52 -0800 Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt From: Cullen Jennings To: "Vijay K. Gurbani" Message-ID: Thread-Topic: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt Thread-Index: AcZHMYnyyHKI17MkEdq0OwARJEEJ/A== In-Reply-To: <4415CF23.2070900@lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 3/13/06 11:59 AM, "Vijay K. Gurbani" wrote: > I am curious: how many proxy servers today support virtual SIP > hosting? I know of several proxies today that will support multiple domains. However, all the ones that I have seen that do TLS require a separate port for each domain. That is because the TLS extensions to specify the domain in the handshake are not that widely used yet. In early versions of HTTP, you needed a port per domain on a web server. This turned out to be undesirable in the long run and got fixed. I would rather not repeat the mistake. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 14 01:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3BP-0005Xf-QB; Tue, 14 Mar 2006 01:39:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3BK-0005GP-Mk for sip@ietf.org; Tue, 14 Mar 2006 01:38:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ2xZ-0006Fm-9R for sip@ietf.org; Tue, 14 Mar 2006 01:24:46 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 13 Mar 2006 22:24:46 -0800 X-IronPort-AV: i="4.02,189,1139212800"; d="scan'208"; a="261662763:sNHT29221288" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2E6Oi1j023051; Mon, 13 Mar 2006 22:24:44 -0800 (PST) Received: from 10.21.83.107 ([10.21.83.107]From sip-bounces@ietf.org Tue Mar 14 01:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3Ay-0005FU-Hj; Tue, 14 Mar 2006 01:38:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3Ax-0005EW-9O for sip@ietf.org; Tue, 14 Mar 2006 01:38:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ38K-0006Ny-81 for sip@ietf.org; Tue, 14 Mar 2006 01:35:53 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Mar 2006 22:35:51 -0800 X-IronPort-AV: i="4.02,189,1139212800"; d="scan'208"; a="261663695:sNHT30120400" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2E6ZpYg009270; Mon, 13 Mar 2006 22:35:51 -0800 (PST) Received: from 10.21.83.107 ([10.21.83.107]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Mar 2006 06:35:51 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Mar 2006 22:35:52 -0800 Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt From: Cullen Jennings To: "Vijay K. Gurbani" Message-ID: Thread-Topic: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt Thread-Index: AcZHMYnyyHKI17MkEdq0OwARJEEJ/A== In-Reply-To: <4415CF23.2070900@lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 3/13/06 11:59 AM, "Vijay K. Gurbani" wrote: > I am curious: how many proxy servers today support virtual SIP > hosting? I know of several proxies today that will support multiple domains. However, all the ones that I have seen that do TLS require a separate port for each domain. That is because the TLS extensions to specify the domain in the handshake are not that widely used yet. In early versions of HTTP, you needed a port per domain on a web server. This turned out to be undesirable in the long run and got fixed. I would rather not repeat the mistake. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 14 01:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3BP-0005Xf-QB; Tue, 14 Mar 2006 01:39:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3BK-0005GP-Mk for sip@ietf.org; Tue, 14 Mar 2006 01:38:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ2xZ-0006Fm-9R for sip@ietf.org; Tue, 14 Mar 2006 01:24:46 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 13 Mar 2006 22:24:46 -0800 X-IronPort-AV: i="4.02,189,1139212800"; d="scan'208"; a="261662763:sNHT29221288" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2E6Oi1j023051; Mon, 13 Mar 2006 22:24:44 -0800 (PST) Received: from 10.21.83.107 ([10.21.83.107]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Mar 2006 06:24:44 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Mar 2006 22:24:44 -0800 Subject: Re: [Sip] The Problem with PRACK From: Cullen Jennings To: Dean Willis Message-ID: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHL/vKOoZGWrMjEdq0OwARJEEJ/A== In-Reply-To: <6BD57E6A-3067-488C-B6A9-5F4E66A60824@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: "sip@ietf.org" , Francois Audet , Paul H 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 On 3/13/06 10:27 AM, "Dean Willis" wrote: > Right. But, SIPS is only required as far as the proxy serving the > AOR. The AOR to Contact vector could be UDP/IPSEC, or even just plain > unsecured UDP. I think we have a gathering amount of evidence that we want to update this regardless of UDP or PRACK. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Mar 2006 06:24:44 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Mar 2006 22:24:44 -0800 Subject: Re: [Sip] The Problem with PRACK From: Cullen Jennings To: Dean Willis Message-ID: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHL/vKOoZGWrMjEdq0OwARJEEJ/A== In-Reply-To: <6BD57E6A-3067-488C-B6A9-5F4E66A60824@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: "sip@ietf.org" , Francois Audet , Paul H 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 On 3/13/06 10:27 AM, "Dean Willis" wrote: > Right. But, SIPS is only required as far as the proxy serving the > AOR. The AOR to Contact vector could be UDP/IPSEC, or even just plain > unsecured UDP. I think we have a gathering amount of evidence that we want to update this regardless of UDP or PRACK. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 01:40:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3BZ-0005iz-Kx; Tue, 14 Mar 2006 01:39:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3B0-0005EW-Ii for sip@ietf.org; Tue, 14 Mar 2006 01:38:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ32m-0006KU-PI for sip@ietf.org; Tue, 14 Mar 2006 01:30:11 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 13 Mar 2006 22:30:08 -0800 X-IronPort-AV: i="4.02,189,1139212800"; d="scan'208"; a="1784638359:sNHT30886474" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2E6U5Yg008338; Mon, 13 Mar 2006 22:30:06 -0800 (PST) Received: from 10.21.83.107 ([10.21.83.107]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Mar 2006 06:30:05 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Mar 2006 22:30:06 -0800 Subject: Re: [Sip] Re: draft-ietf-sip-outbound-02 From: Cullen Jennings To: Dean Willis , Paul H Kyzivat Message-ID: Thread-Topic: [Sip] Re: draft-ietf-sip-outbound-02 Thread-Index: AcZHMLu3+i/HObMjEdq0OwARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 3/13/06 10:12 AM, "Dean Willis" wrote: > > On Mar 12, 2006, at 4:26 PM, Paul Kyzivat wrote: > >>> Hmm, we probably need to fix some text here. I don't actually see >>> how it >>> matters if the UA supports the path header or not. It's the >>> registrar that >>> needs to support it. >> >> The way that Path is specified, the UAC is supposed to indicate >> support before the proxies use it. Technically, things could still >> work fine without the UAC being complicit, but this is a constraint >> in the RFC. > > We added this behavior in PATH at the insistence of some security > types. Others also viewed it as an OPES and/or UNSAF issue, which > could perhaps explain just how confusing the whole proxy-routing > model in SIP actually is. > > The idea behind Supported: path is that if the UA understands Path, > then it has the ability to perform validation of received Path > vectors to detect "unexpected proxies" that are presumed to be MITM > attackers on its vector. It might also do run time analysis of Route > and Via against Path to make sure everything is well-behaved. > > In practical reality, we seem to trust SIP proxies as implicitly as > we trust IP routers, and expect routes to change periodically as > topologies adapt. Of course, we can't re-route mid-dialog, meaning we > just get a failure scenario for dialogs that are affected by a > topology change unless subtle and complex (and unspecified by IETF) > redundancy measures have been applied at the proxy layer. > > Also in practice, no UA that I know of pays any attention to the > returned Path header field, and many systems are refusing to return > it because they believe letting the UA know about the route of its > requests violates the proxy-operator's veil of secrecy, which they > hold to be a Good Thing. > > This lends credence to the argument that proxy-routing should be a > single-layered special-case negotiated and controlled by the UAs (the > "outbound" case) rather than the multi-layered, invisible to the UA > service-invoking model that IMS uses. > > -- > Dean What can I say :-) Do you think we should do anything to update drafts that mandate you do something that no one knows how to do (and the draft provides no hits on how to do) and no one does? Probably not given we have more important things but depressing all the same. Anyway, it is easy to fix outbound to be consistent with this. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 02:01:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3VT-0007OZ-KZ; Tue, 14 Mar 2006 01:59:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3VS-0007OU-5X for sip@ietf.org; Tue, 14 Mar 2006 01:59:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ3VP-00077r-Lk for sip@ietf.org; Tue, 14 Mar 2006 01:59:45 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Mar 2006 22:59:44 -0800 X-IronPort-AV: i="4.02,189,1139212800"; d="scan'208"; a="261666684:sNHT30989316" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2E6xeYg016484; Mon, 13 Mar 2006 22:59:43 -0800 (PST) Received: from 10.21.83.107 ([10.21.83.107]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Mar 2006 06:59:40 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Mar 2006 22:59:40 -0800 Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 From: Cullen Jennings To: Hans Persson , Dean Willis Message-ID: Thread-Topic: [Sip] SBCs and draft-ietf-sip-identity-06 Thread-Index: AcZHNN0aG+bi9LMoEdq0OwARJEEJ/A== In-Reply-To: <1141889747.14635.5.camel@eeek.ingate.se> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable 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 On 3/8/06 11:35 PM, "Hans Persson" wrote: > tis 2006-03-07 klockan 11:54 -0600 skrev Dean Willis: >=20 >>> Both these functions are nice in an ideal world, but many people >>> will have SBCs, B2BUAs, or SIP-aware firewalls in their call paths. >>> These will modify SDP and probably the Contact header. >>>=20 >>> As far as I can see there is no discussion in the draft about this >>> at all, apart from the probably na=C4=A9ve assumption that it shouldn't >>> happen. >>=20 >> That's because IT SHOULDN'T HAPPEN. >>=20 >> A B2BUA is NOT A proxy, and is NOT, in general, identity-transparent >=20 > No, it shouldn't happen. I'm just saying that it will, in reality. >=20 > I think it would be a good idea if new specs state explicitly if they > are going to break in common deployment scenario types instead of just > pretending that no problem exists. >=20 > Hans I doubt that Identity breaks B2BUA in the cases that I have heard of. I roughly break the cases into two classes - ones where the B2BUA wants to assert a new identity because it is hiding the old one; And cases where it is in the same domain as the original party. In either case the B2BUA can have the credentials to be able to re-sign the identity in the message. I'm won't be surprised if someone comes up with a case where it is a problem bu= t so far, everyone I have heard of has not been a problem. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 02:26:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3tA-0002Mq-1W; Tue, 14 Mar 2006 02:24:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3sR-0001pb-5V for sip@ietf.org; Tue, 14 Mar 2006 02:23:31 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ3dC-0007Uw-Nq for sip@ietf.org; Tue, 14 Mar 2006 02:07:50 -0500 Received: from [206.176.144.212] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2E784Nb010380 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 14 Mar 2006 01:08:06 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86D8A657-B8C7-4184-A5BF-C20381789F34@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Tue, 14 Mar 2006 01:07:39 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "sip@ietf.org" , Francois Audet , Paul H 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 On Mar 14, 2006, at 12:24 AM, Cullen Jennings wrote: > On 3/13/06 10:27 AM, "Dean Willis" wrote: > >> Right. But, SIPS is only required as far as the proxy serving the >> AOR. The AOR to Contact vector could be UDP/IPSEC, or even just plain >> unsecured UDP. > > I think we have a gathering amount of evidence that we want to > update this > regardless of UDP or PRACK. It's true that SIP proxies just don't work "right" with SIPS as it is. When people first look at the "SIPS is only valid to the serving proxy" model they assume that simply changing the requirement to say that the proxy-to-UA leg must also be SIPS protected would provide a satisfactory answer. It doesn't, and this requires some careful thinking. What security do you mandate on the serving-proxy to UA link? TLS? TLS supports many different ciphersuites. What keeps the crypto on the SP-UA link from being watered-down? Would other protections like IPSEC suffice? How would you end-to-end negotiate the cryptography so that the originating UA could believe that the entire chain was protected to some minimal level? And how do you offer some level of security to an IMS fashion-victim who is always going to be exposed to MITM attacks from his own service provider by design? Personally, I think the only way SIPS really gives us the level of protection we have come to expect from HTTPS is if it is used end-to- end, either by abandoning proxy-routing in favor of a redirect model, or by causing the proxies to be cryptographically transparent as is done with HTTPS proxies. This is an important thing to note: HTTPS proxies do NOT "see inside" the HTTPS stream. All they do is pass it along, unchanged, to the next hop. It could actually be some other protocol than HTTP, and they don't care and can't tell. To-date, we haven't treated SIPS proxies that way, and instead presume they have access to the full stream, in many cases "write access" so that they can munge various header fields about. -- 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 Mar 14 02:50:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ4Gu-0005pA-RF; Tue, 14 Mar 2006 02:48:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ4Gu-0005p5-1I for sip@ietf.org; Tue, 14 Mar 2006 02:48:48 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ4Gp-000060-Dn for sip@ietf.org; Tue, 14 Mar 2006 02:48:47 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k2E7mbc1022132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Mar 2006 08:48:37 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k2E7mWt8008235; Tue, 14 Mar 2006 08:48:32 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k2E7mQjD008234; Tue, 14 Mar 2006 08:48:26 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 From: Hans Persson To: Cullen Jennings In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Organization: Ingate Systems Date: Tue, 14 Mar 2006 08:48:26 +0100 Message-Id: <1142322506.6820.1.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Tue, 14 Mar 2006 08:48:37 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "sip@ietf.org" , 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 m=E5n 2006-03-13 klockan 22:59 -0800 skrev Cullen Jennings: > I doubt that Identity breaks B2BUA in the cases that I have heard of. I > roughly break the cases into two classes - ones where the B2BUA wants to > assert a new identity because it is hiding the old one; And cases where i= t > is in the same domain as the original party. In either case the B2BUA can > have the credentials to be able to re-sign the identity in the message. I= 'm > won't be surprised if someone comes up with a case where it is a problem = but > so far, everyone I have heard of has not been a problem. I'd rather expect problem in the opposite direction. If the B2BUA wants to terminate incoming calls, then the receiving client won't be able to verify the identity of the caller since the B2BUA will have modified the body (at least) of the incoming request since the creation of the Identity header. Hans --=20 Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 03:41:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ54X-0005FK-EI; Tue, 14 Mar 2006 03:40:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FImiX-0000MT-Aa for sip@ietf.org; Mon, 13 Mar 2006 08:04:09 -0500 Received: from mail1.abbeynet.it ([151.9.176.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FImiU-0005gI-UI for sip@ietf.org; Mon, 13 Mar 2006 08:04:09 -0500 Received: from mail1.abbeynet.it (localhost.localdomain [127.0.0.1]) by mail1.abbeynet.it (Postfix) with SMTP id 40FF9547A9 for ; Mon, 13 Mar 2006 14:04:05 +0100 (CET) Received: from [192.168.2.226] (unknown [192.168.2.226]) by mail1.abbeynet.it (Postfix) with ESMTP id 2F6E4547A9 for ; Mon, 13 Mar 2006 14:04:05 +0100 (CET) Message-ID: <44156DC4.4060105@abbeynet.com> Date: Mon, 13 Mar 2006 14:04:04 +0100 From: Giacomo Vacca User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] SIP codecs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-Mailman-Approved-At: Tue, 14 Mar 2006 03:40:04 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Francesco, as stated in RFC 3264 (An Offer/Answer Model for SDP), =A76.1: " The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). " I hope it's useful. Regards, Giacomo Paradiso, Francesco wrote: > Hi all, > if a UAC send an invite with codec "X" and "Y", it should be possible=20 > that a 200ok is received with codec "Z","X" and "Y" ? > or the 200ok must be sent with a sub-set of supported codec? > Is there an RFC that refer to this behaviour? > =20 > Thanks in advance and Best Regards > Francesco=20 > =20 > > > __________ NOD32 1.1440 (20060312) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.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 > >__________ NOD32 1.1440 (20060312) Information __________ > >This message was checked by NOD32 antivirus system. >http://www.eset.com > > =20 > --=20 ing. Giacomo Vacca Product Manager Abbeynet SpA Viale Monastir Km. 8,200 - ex S.S. 131 casella postale 79 09028 Sestu (CA), Italy Piazza Rondanini 48 00186 Roma ----------------------------------- giacomo.vacca@abbeynet.com phone: +39 070 2339346 voip: sip:0702339346@extra.sip.abbeynet.it enum: +88299 002440 46 mobile: +39 3928454855 fax: +39 070 229016 ----------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 03:55:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ5Hf-0003c5-6n; Tue, 14 Mar 2006 03:53:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ5He-0003Zj-JY for sip@ietf.org; Tue, 14 Mar 2006 03:53:38 -0500 Received: from 207-170-229-131.gen.twtelecom.net ([207.170.229.131] helo=svr-wa-e2k1.usa.alliedtelesyn.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ5Hc-0001zK-89 for sip@ietf.org; Tue, 14 Mar 2006 03:53:38 -0500 Received: from alliedtelesyn.com ([10.17.252.2]) by svr-wa-e2k1.usa.alliedtelesyn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 00:53:35 -0800 Received: from svr-mila-e2k1.eu.alliedtelesyn.com ([10.17.39.14] RDNS failed) by alliedtelesyn.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Mar 2006 09:44:19 +0100 Received: from svr-mila-fs3.eu.alliedtelesyn.com ([10.17.90.11]) by svr-mila-e2k1.eu.alliedtelesyn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 09:53:34 +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] SIP codecs X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 14 Mar 2006 09:53:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP codecs Thread-Index: AcZHQxVmjOkkKoSMTECCLxkUfpG/wQAAWS/g From: "Paradiso, Francesco" To: X-OriginalArrivalTime: 14 Mar 2006 08:53:34.0137 (UTC) FILETIME=[C690E290:01C64744] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Thanks to all, I deduce that other codecs should be set in the list, but the order MUST = be based on priority. Best Regards Francesco =20 -----Original Message----- From: Giacomo Vacca [mailto:giacomo.vacca@abbeynet.com]=20 Sent: Monday, March 13, 2006 2:04 PM To: sip@ietf.org Subject: Re: [Sip] SIP codecs Hi Francesco, as stated in RFC 3264 (An Offer/Answer Model for SDP), =A76.1: " The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). " I hope it's useful. Regards, Giacomo Paradiso, Francesco wrote: > Hi all, > if a UAC send an invite with codec "X" and "Y", it should be possible=20 > that a 200ok is received with codec "Z","X" and "Y" ? > or the 200ok must be sent with a sub-set of supported codec? > Is there an RFC that refer to this behaviour? > =20 > Thanks in advance and Best Regards > Francesco > =20 > > > __________ NOD32 1.1440 (20060312) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.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 > >__________ NOD32 1.1440 (20060312) Information __________ > >This message was checked by NOD32 antivirus system. >http://www.eset.com > > =20 > -- ing. Giacomo Vacca Product Manager Abbeynet SpA Viale Monastir Km. 8,200 - ex S.S. 131 casella postale 79 09028 Sestu (CA), Italy Piazza Rondanini 48 00186 Roma ----------------------------------- giacomo.vacca@abbeynet.com phone: +39 070 2339346 voip: sip:0702339346@extra.sip.abbeynet.it enum: +88299 002440 46 mobile: +39 3928454855 fax: +39 070 229016 ----------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu for questions on current sip Use = sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 05:24:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ6fd-00021q-Dv; Tue, 14 Mar 2006 05:22:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ6fb-00021l-Rh for sip@ietf.org; Tue, 14 Mar 2006 05:22:27 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ6fa-0004cM-DJ for sip@ietf.org; Tue, 14 Mar 2006 05:22:27 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2EALDTE009626; Tue, 14 Mar 2006 12:21:13 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 12:22:23 +0200 Received: from [172.21.36.142] ([172.21.36.142]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 14 Mar 2006 12:22:22 +0200 Message-ID: <44169961.2080909@nokia.com> Date: Tue, 14 Mar 2006 12:22:25 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Dean Willis Subject: Re: [Sip] The Problem with PRACK References: <86D8A657-B8C7-4184-A5BF-C20381789F34@softarmor.com> In-Reply-To: <86D8A657-B8C7-4184-A5BF-C20381789F34@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2006 10:22:22.0766 (UTC) FILETIME=[2EAD24E0:01C64751] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Cullen Jennings , "sip@ietf.org" , Francois Audet , Paul H 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 ext Dean Willis wrote: > Personally, I think the only way SIPS really gives us the level of > protection we have come to expect from HTTPS is if it is used > end-to-end, either by abandoning proxy-routing in favor of a redirect > model, or by causing the proxies to be cryptographically transparent as > is done with HTTPS proxies. I agree with you here. But there seems to be quite considerable pushback in this community towards HTTP connect. After all, this wasn't an option even for MSRP, and there backwards compatibility wasn't an issue, as it most definitely is here. > This is an important thing to note: HTTPS proxies do NOT "see inside" > the HTTPS stream. All they do is pass it along, unchanged, to the next > hop. It could actually be some other protocol than HTTP, and they don't > care and can't tell. To-date, we haven't treated SIPS proxies that way, > and instead presume they have access to the full stream, in many cases > "write access" so that they can munge various header fields about. Yup. There are of course folks that think hop-by-hop is a good thing, because it potentially enables secure media while letting LI boxes recover the session keys. Except if something like DTLS with public key authentication is used, instead of, say, the PSK ciphersuites. Cheers, Aki > -- > 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 Mar 14 07:15:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ8PE-000082-9v; Tue, 14 Mar 2006 07:13:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ8PC-00007x-Hs for sip@ietf.org; Tue, 14 Mar 2006 07:13:38 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ8PA-0007XY-LO for sip@ietf.org; Tue, 14 Mar 2006 07:13:38 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2EC8WlN017562; Tue, 14 Mar 2006 14:08:32 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 14:08:32 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 14:08:31 +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] The Problem with PRACK Date: Tue, 14 Mar 2006 14:08:30 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0212E9C4@esebe103.NOE.Nokia.com> In-Reply-To: <441057B9.8010602@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDlqOrQGOJVrmUTly6shAze7mvMADxu20g From: To: , X-OriginalArrivalTime: 14 Mar 2006 12:08:31.0796 (UTC) FILETIME=[02E9FF40:01C64760] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 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 Hi, >> PRACK dilemma. Why not revise PRACK so that you can't send an offer or=20 >> answer with it; it has no impact on the set of allowed O/A exchanges=20 >> defined by RFC 3261.=20 > In any case, any change like this must be accompanied by a some strategy=20 > for backward compatibility. This seems not so easy. As much as it is fun=20 > to imagine how it might have been done better the first time around, I > suspect that at this point the cure is worse than the disease. I would just like to point out that the session setup specified for 3GPP IMS networks uses preconditions and implicitely assume sending an offer within PRACK. This is done for efficiency reasons like Paul indicated: >Allowing an offer in PRACK is less motivated. Essentially the=20 >same thing=20 >can be done using UPDATE. I can speculate on some reasons for allowing=20 >PRACK to be used for this: >- efficiency - the prack is required anyway The 3GPP call setup with preconditions consists of 4 SIP transactions: INVITE, two PRACKs for reliable responses and one UPDATE, covering two to three offer-answer exchanges. All this (performed over long-range radio access) will take considerable amount of time, more than 10 seconds in the worst case. Adding yet another UPDATE transaction to those would make the setup time even longer. This far 3GPP has adopted a strategy to be compliant to IETF specs. However obsoleting PRACK to contain an SDP offer would have a backward compatibility problem towards all 3GPP compliant implementations, whether they would be applied within IMS networks or Internet. Anyway the issue here is that for any transport requiring resource reservation (and preconditions) and providing long RTT, this kind of change would push session setup times to their limits, no more acceptable to average users. Regards, Erkki >-----Original Message----- >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 >Sent: 09.March.2006 18:29 >To: Prince A P >Cc: sip@ietf.org >Subject: Re: [Sip] The Problem with PRACK > > > >Prince A P wrote: >> Hi, >> =20 >> If the 3262 is only for Reliability of Provisional=20 >responses, Why should >> it mandate Offer-Answer completion? >> Was there any rationale behind clubbing Reliability with=20 >Offer-Answer? > >I wasn't there when that was done, so I can't speak to the actual=20 >motives of those who were. > >But note that offer/answer has no mechanism of its own - it must be=20 >associated with some messages in the signaling system. > >Reliable provisionals, without sdp in the PRACK, are sufficient for=20 >early completion of the offer/answer exchange when the offer is in the=20 >invite. But that isn't sufficient to achieve early completion of=20 >offer/answer when there is no offer in the invite. In that case the=20 >offer is in the reliable provisional, and the obvious place for the=20 >answer is in the PRACK. That seems to be reasonable justification for=20 >involving PRACK in offer/answer. > >Allowing an offer in PRACK is less motivated. Essentially the=20 >same thing=20 >can be done using UPDATE. I can speculate on some reasons for allowing=20 >PRACK to be used for this: >- done before UPDATE was invented >- efficiency - the prack is required anyway >- prack already needs to carry an answer, why not an offer > > Paul > >> =20 >> rgds, >> Prince >>=20 >>=20 >> =20 >>=20 >> To: "Samir Srivastava" < samirsr@nortel.com >> >, "Paul Kyzivat"=20 >> >, "Francois Audet" < >> audet@nortel.com > >> From: "Samir Srivastava" < samirsr@nortel.com >> > >> Date: 03/09/2006 01:18PM >> cc: IETF SIP List > >> Subject: RE: [Sip] The Problem with PRACK >>=20 >> We can do it, by adding more logic / header. UAS=20 >knows about all the >> hops by complete via header set inspection. When=20 >sending 1xx, it >> need to >> indicate in this new header to be defined. Is it worth >> defining this ? >>=20 >>=20 >> Thx >> Samir >>=20 >> -----Original Message----- >> From: Srivastava, Samir [SC100:8826:EXCH] >> Sent: Wednesday, March 08, 2006 11:19 PM >> To: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH] >> Cc: IETF SIP List >> Subject: RE: [Sip] The Problem with PRACK >>=20 >> We can do for SIPS only. >>=20 >> Thx >> Samir >>=20 >> -----Original Message----- >> From: Paul Kyzivat [ mailto:pkyzivat@cisco.com] >> Sent: Wednesday, March 08, 2006 7:29 PM >> To: Audet, Francois [SC100:3055:EXCH] >> Cc: IETF SIP List >> Subject: Re: [Sip] The Problem with PRACK >>=20 >>=20 >>=20 >> Francois Audet wrote: >> > I'm ok with the suggestion to deprecate using PRACK for >> Offer/Answer. >> > >> > While we are at it, why not go for deprecating=20 >the use PRACK >> > altogether when TCP transport is used? >>=20 >> Explain to me again how you would know that reliable=20 >transport >> is used >> end to end? >>=20 >> Paul >>=20 >> > On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: >> > >> >> Hi, >> >> >> >> A things about PRACK come immediately to mind=20 >that are a pain to >> >> implement: >> >> >> >> 1) The UAS has to queue provisionals until it receives a >> PRACK for >> >> the first provisional. This is due to RSeq=20 >starting at an >> arbitrary >> >> value instead of just starting at 1. This is=20 >probably the >> simplest >> >> to fix, by just requiring the UAC to always start with a >> RSeq of 1. >> >> >> >> 2) Multiple unacknowledged provisionals can be=20 >in flight at >> the same >> >> time. We could potentially eliminate this requirement by >> >> acknowledging the current status instead of the whole >> history. In >> >> other words, when the UAS sends a new reliable=20 >provisional, it >> >> decides which (if any) of the previously sent=20 >provisionals >> are still >> >> relevant and sends all of them (as sipfrags or=20 >something) as >> a single >>=20 >> >> reliable request. >> >> >> >> 3) If you "answer" and want to deliver a 200 OK,=20 >you have to >> queue it >>=20 >> >> and wait if you are waiting for a PRACK to an=20 >offer or answer. >> >> Keeping track of when you can send the 200 would=20 >be easier >> if we did >> >> something like I recommend in #2. >> >> >> >> 4) Even for an acknowledged provisional, you=20 >still have to >> retransmit >>=20 >> >> approximately every minute (I forget exactly) to=20 >prevent old >> proxies >> >> from deleting state for your transaction. This is one of >> those minor >>=20 >> >> annoyances that is *almost* operationally irrelevant, and >> unlikely to >>=20 >> >> not get coded. My proposal for simplification is to >> retransmit the >> >> latest reliable provisional in exactly the same=20 >way that the >> UAS >> >> retransmits unreliable provisionals. Who cares=20 >if there is >> an extra >> >> message or two for a call with 1 minute +=20 >post-answer delay? >> >> >> >> 5) I would deprecate the PRACK/200 (PRACK) offer/answer >> exchange. I >> >> talked Jonathan into this, and I've been sorry I did ever >> since. My >> >> apologies to everyone for making a bad decision. >> >> >> >> Hope this helps. >> >> thanks, >> >> -rohan >> >> >> >> On 3/7/06, *Jonathan Rosenberg* < jdrosen@cisco.com >> >> >> > wrote: >> >> >> >> At the last IETF, there was a lot of discussion and >> argument >> around >> >> PRACK. The spark of this debate was the ICE >> specification, which >> had >> >> words in it requiring the usage of PRACK and=20 >UPDATE in >> order to >> work >> >> with early media. There was strong pushback from many >> implementors >> >> that >> >> anything requiring PRACK is unacceptable.=20 >Rohan put up a >> slide >> (IIRC) >> >> that showed the state machine in his implementation >> resulting >> from >> >> PRACK, and it was not pretty. >> >> >> >> So, I'd like to discuss exactly what IS the=20 >problem with >> PRACK? >> There >> >> are really two pieces of state machinery in=20 >play here. >> One piece >> >> is the >> >> complication that PRACK introduces into the=20 >offer/answer >> model. >> With >> >> PRACK, you can now get a final answer in the 18x, and >> then send a >> new >> >> offer in UPDATE, or even in PRACK itself.=20 >Another piece >> is the >> state >> >> machinery with the retransmissions itself -=20 >correlating >> the PRACK >> >> with a >> >> particular reliable provisional response and=20 >causing it >> to stop. >> >> >> >> In a chat with Flemming today, he suggested in >> interested remedy >> >> to our >> >> PRACK dilemma. Why not revise PRACK so that you can't >> send an >> offer or >> >> answer with it; it has no impact on the set=20 >of allowed O/A >> exchanges >> >> defined by RFC 3261. I'm not sure if that would >> consequently >> break the >> >> preconditions mechanism, but maybe there are=20 >some kind of >> offer/answer >> >> limitations that would simplify things. >> >> >> >> So, this is one idea. I'd like for people who have >> complained >> about >> >> PRACK implementations to speak up and indicate what >> exactly makes >> >> it so >> >> complicated for them. >> >> >> >> Thanks, >> >> Jonathan R. >> >> -- >> >> Jonathan D. Rosenberg, Ph.D. 600 >> Lanidex Plaza >> >> Cisco Fellow =20 >> Parsippany, NJ >> >> 07054-2711 >> >> Cisco Systems >> >> jdrosen@cisco.com >> >> < mailto:jdrosen@cisco.com> =20 > =20 >> FAX: =20 >> >> (973) 952-5050 >> >> http://www.jdrosen.net=20 > =20 >> PHONE: (973) >> 952-5000 >> >> http://www.cisco.com >> >> >> >> _______________________________________________ >> >> Sip mailing list =20 >> https://www1.ietf.org/mailman/listinfo/sip >> >> > > >> >> This list is for NEW development of the core=20 >SIP Protocol >> >> Use sip-implementors@cs.columbia.edu >> >> >> =20 >for questions on >> current sip >> >> Use sipping@ietf.org < >> mailto:sipping@ietf.org> for new >> >> developments on the application of sip >> >> >> >> >> >> _______________________________________________ >> >> Sip mailing list =20 >https://www1.ietf.org/mailman/listinfo/sip >> >> This list is for NEW development of the core SIP=20 >Protocol Use >> >> sip-implementors@cs.columbia.edu >> >> >> for=20 >questions on >> current >> >> sip Use sipping@ietf.org < >> mailto:sipping@ietf.org> for new >> >> developments on the application of sip >> > >> > >> > >> > >> =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 >> > 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=20 >developments >> on the application of sip >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on >> current sip >> Use sipping@ietf.org for new >> developments on the application of sip >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> >> This list is for NEW development of the core SIP 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 >>=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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 07:34:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ8hd-0000mG-R4; Tue, 14 Mar 2006 07:32:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ8hc-0000mB-8U for sip@ietf.org; Tue, 14 Mar 2006 07:32:40 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ8ha-0007l1-TY for sip@ietf.org; Tue, 14 Mar 2006 07:32:40 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 470AE14040C; Tue, 14 Mar 2006 14:32:37 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 0A09F140407; Tue, 14 Mar 2006 14:32:24 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id A797CF027E; Tue, 14 Mar 2006 14:32:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17430.47090.634650.930408@rautu.tutpro.com> Date: Tue, 14 Mar 2006 14:32:50 +0200 From: Juha Heinanen To: Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0212E9C4@esebe103.NOE.Nokia.com> References: <441057B9.8010602@cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F0212E9C4@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.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 Erkki.Koivusalo@nokia.com writes: > The 3GPP call setup with preconditions consists of 4 SIP transactions: > INVITE, two PRACKs for reliable responses and one UPDATE, covering > two to three offer-answer exchanges. why do you use prack rather than tcp or just udp with retransmissions in case 200 OK gets lost? -- 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 Mar 14 07:48:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ8vW-0006yn-Uh; Tue, 14 Mar 2006 07:47:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ8vV-0006yi-UN for sip@ietf.org; Tue, 14 Mar 2006 07:47:01 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ8vU-0007yT-Fd for sip@ietf.org; Tue, 14 Mar 2006 07:47:01 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2ECjjjQ007893; Tue, 14 Mar 2006 14:45:45 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 14:46:55 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 14:46: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] The Problem with PRACK Date: Tue, 14 Mar 2006 14:46:55 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0212EA48@esebe103.NOE.Nokia.com> In-Reply-To: <17430.47090.634650.930408@rautu.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHY2wepjyRKpnAQ+W5ce+IEOE/dQAAOUwA From: To: X-OriginalArrivalTime: 14 Mar 2006 12:46:55.0785 (UTC) FILETIME=[6032D190:01C64765] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.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, Like already explained in this thread, SIP does not have a way to request or guarantee end-to-end TCP. And when using UDP, the important response that might get lost is a provisional=20 one like 180 or 183 (losing 200 is another case).=20 If such a provisional response (with SDP due to applying=20 preconditions) can get lost, there is no other mechanism than PRACK to inform the sender of the response that the response was actually correctly received. Provisional responses are not retransmitted by default, they are retransmitted only when there is the Require: 100rel header and PRACK does not arrive on time. Regards, Erkki=20 >-----Original Message----- >From: ext Juha Heinanen [mailto:jh@tutpro.com]=20 >Sent: 14.March.2006 14:33 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: pkyzivat@cisco.com; princeap@gmail.com; sip@ietf.org >Subject: RE: [Sip] The Problem with PRACK > >Erkki.Koivusalo@nokia.com writes: > > > The 3GPP call setup with preconditions consists of 4 SIP=20 >transactions: > > INVITE, two PRACKs for reliable responses and one UPDATE, covering > > two to three offer-answer exchanges. > >why do you use prack rather than tcp or just udp with=20 >retransmissions in >case 200 OK gets lost? > >-- 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 Mar 14 07:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ8wm-0007bx-SX; Tue, 14 Mar 2006 07:48:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ8wk-0007bs-Mg for sip@ietf.org; Tue, 14 Mar 2006 07:48:18 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ8wk-00080J-2l for sip@ietf.org; Tue, 14 Mar 2006 07:48:18 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 59BA2F96; Tue, 14 Mar 2006 13:48:17 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 13:48:16 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 13:48:16 +0100 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] Myth Busters: Episode 1, Is STUN request processingfaster than a SIP PING request processing? Date: Tue, 14 Mar 2006 13:48:16 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B4D@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processingfaster than a SIP PING request processing? Thread-Index: AcZGEMLnAZKxbbIEEdqjXwARJEEJ/ABU9AmA From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "Hisham Khartabil" , X-OriginalArrivalTime: 14 Mar 2006 12:48:16.0849 (UTC) FILETIME=[90843410:01C64765] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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, Without commenting on the "speed" issue, IF we want to use a SIP based solution I would prefear a dedicated one, instead of re-using OPTIONS. Like I said earlier, IF the edge proxy "understands" the mechanism, and IF it knows the request does not need to be forwarded, it can choose to terminate it. Yes, it's b2bua behaviour, but still. I do not want a solution that forces me to overload the rest of the network with the keep-alive requests - no matter what mechanism is used - and therefor OPTIONS is not a good solution, because since OPTIONS would also be used for non-keep-alive purposes it would always have to be forwarded. Another solution, as I mentioned earlier, would be that the keep-alives are addressed to the edge proxy (or whatever entity on the other side of the NAT). Then it would be "normal SIP", without any b2bua behavior. Regards, Christer -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: 12. maaliskuuta 2006 22:09 To: Hisham Khartabil; sip@ietf.org Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processingfaster than a SIP PING request processing? You results don't look right to me. I can't really test very well on my notebook computer but with STUN on a apple powerbook I am getting 16,000 TPS at about 30% CPU. Who knows what I could get with an intel processor :-) Your results look like 6 to 10k TPS. When people quote ms I never have any clue if they are including the kernel time, it it is a latency or what. The number we need here is aggregate throughput, not latency so actual transactions per second on some suitable box might be the easies to compare. Similarly, the rates of OPTIONS also looked fairly slow so perhaps I just don't get what you are measuring. Ignoring that, when I look at the code, I can't see any particular reason that the speed of PING would not be roughly the same as STUN. The problem is this violates RFC 3261 in so many ways that you can barely make a list of them all. Once you do the processing to make this consistent with existing things, the performance will drop significantly - my guess is that it would drop to roughly the same rate as OPTION. On 3/6/06 10:02 AM, "Hisham Khartabil" wrote: > I promised to come back with hard real numbers on how long it will=20 > take for a server to process and STUN request vs a SIP PING request >=20 > Myth: processing a STUN request is 10 to 100 times faster than a SIP=20 > PING request >=20 > Assumptions: - SIP PING request is processed early in the stack and=20 > bypasses any unnecessary validations. > - SIP PING response carries in the contact header the=20 > IP address and port as appears in the IP packet (source IP and port). >=20 > We implemented the PING request as described above in the reSIProcate=20 > stack. Attached you will find the c++ file where the changes were made. > STUN was already implemented in the reSIProcate stack and used as is. >=20 > Below you will see the findings: >=20 > STUN request processing: 0.15 - 0.2 ms SIP PING request processing:=20 > 0.1 - 0.2 ms SIP OPTIONS request: 7 ms SIP REGISTER request: 7 ms >=20 > The measurement was taken between the time a request appeared on=20 > ethereal and its response appearing on ethereal. Average was taken=20 > manually. >=20 > As you can see, SIP PING requests were sometimes faster to process=20 > that STUN requests, but never slower. Actually the SIP PING requests=20 > on average were faster to process. >=20 > Myth Busted!!!! :) >=20 > Regards, > Hisham > P.S. It took 15 mins to modify the sip stack to do the PING response. >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 08:01:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ97Z-0004Uy-Iu; Tue, 14 Mar 2006 07:59:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ97X-0004OG-PM for sip@ietf.org; Tue, 14 Mar 2006 07:59:27 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ97W-0008Ov-J4 for sip@ietf.org; Tue, 14 Mar 2006 07:59:27 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 72E29AC6; Tue, 14 Mar 2006 13:59:23 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 13:59:22 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 13:59:22 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] The Problem with PRACK Date: Tue, 14 Mar 2006 13:59:21 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B4E@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDE2S9Uw7HnI7DRM2AObg6DmaTWQAGpO1QAQ48HDA= From: "Christer Holmberg \(JO/LMF\)" To: "Arunachalam Venkatraman \(arunvenk\)" , "Rohan Mahy" , "Jonathan Rosenberg \(jdrosen\)" X-OriginalArrivalTime: 14 Mar 2006 12:59:22.0055 (UTC) FILETIME=[1D029570:01C64767] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 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="===============1209664257==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1209664257== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64767.1CCF841A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64767.1CCF841A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 A long time ago, I proposed a solution which would not require the queueing: the INVITE request would contain the RSeq value that the UAS MUST use for the FIRST reliable provisional response. =20 Regards, =20 Christer =20 ________________________________ From: Arunachalam Venkatraman (arunvenk) [mailto:arunvenk@cisco.com]=20 Sent: 9. maaliskuuta 2006 6:06 To: Rohan Mahy; Jonathan Rosenberg (jdrosen) Cc: IETF SIP List Subject: RE: [Sip] The Problem with PRACK Regarding 1 below about having to queue up provisionals pending PRACK for first one, an additional nuance is that it is also required to queue up provisionals even after the first is PRACKed and send them one at a time, as the PRACK for each is received. If this were not done, then the PRACKS may be received out of sequence and mess up the CSeq check for requests received at the UAS. Then the UAS will futilely continue to retransmit the provisionals with no hope of ever matching the PRACKS that were returned a 500 response due to out-of-sequence receipt. ________________________________ From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 Sent: Wednesday, March 08, 2006 5:51 PM To: Jonathan Rosenberg (jdrosen) Cc: IETF SIP List Subject: Re: [Sip] The Problem with PRACK Hi, A things about PRACK come immediately to mind that are a pain to implement: 1) The UAS has to queue provisionals until it receives a PRACK for the first provisional. This is due to RSeq starting at an arbitrary value instead of just starting at 1. This is probably the simplest to fix, by just requiring the UAC to always start with a RSeq of 1.=20 2) Multiple unacknowledged provisionals can be in flight at the same time. We could potentially eliminate this requirement by acknowledging the current status instead of the whole history. In other words, when the UAS sends a new reliable provisional, it decides which (if any) of the previously sent provisionals are still relevant and sends all of them (as sipfrags or something) as a single reliable request.=20 3) If you "answer" and want to deliver a 200 OK, you have to queue it and wait if you are waiting for a PRACK to an offer or answer. Keeping track of when you can send the 200 would be easier if we did something like I recommend in #2. =20 4) Even for an acknowledged provisional, you still have to retransmit approximately every minute (I forget exactly) to prevent old proxies from deleting state for your transaction. This is one of those minor annoyances that is *almost* operationally irrelevant, and unlikely to not get coded. My proposal for simplification is to retransmit the latest reliable provisional in exactly the same way that the UAS retransmits unreliable provisionals. Who cares if there is an extra message or two for a call with 1 minute + post-answer delay?=20 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I talked Jonathan into this, and I've been sorry I did ever since. My apologies to everyone for making a bad decision. Hope this helps. thanks, -rohan On 3/7/06, Jonathan Rosenberg wrote:=20 At the last IETF, there was a lot of discussion and argument around PRACK. The spark of this debate was the ICE specification, which had words in it requiring the usage of PRACK and UPDATE in order to work with early media. There was strong pushback from many implementors that=20 anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) that showed the state machine in his implementation resulting from PRACK, and it was not pretty. =09 So, I'd like to discuss exactly what IS the problem with PRACK? There=20 are really two pieces of state machinery in play here. One piece is the complication that PRACK introduces into the offer/answer model. With PRACK, you can now get a final answer in the 18x, and then send a new offer in UPDATE, or even in PRACK itself. Another piece is the state machinery with the retransmissions itself - correlating the PRACK with a particular reliable provisional response and causing it to stop. =09 In a chat with Flemming today, he suggested in interested remedy to our=20 PRACK dilemma. Why not revise PRACK so that you can't send an offer or answer with it; it has no impact on the set of allowed O/A exchanges defined by RFC 3261. I'm not sure if that would consequently break the preconditions mechanism, but maybe there are some kind of offer/answer limitations that would simplify things. =09 So, this is one idea. I'd like for people who have complained about PRACK implementations to speak up and indicate what exactly makes it so=20 complicated for them. =09 Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems=20 jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C64767.1CCF841A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
A long=20 time ago, I proposed a solution which would not require the queueing: = the INVITE=20 request would contain the RSeq value that the UAS MUST use for the FIRST = reliable provisional response.
 
Regards,
 
Christer
 

From: Arunachalam Venkatraman = (arunvenk)=20 [mailto:arunvenk@cisco.com]
Sent: 9. maaliskuuta 2006=20 6:06
To: Rohan Mahy; Jonathan Rosenberg = (jdrosen)
Cc: IETF=20 SIP List
Subject: RE: [Sip] The Problem with=20 PRACK

Regarding 1 below about having to queue up = provisionals=20 pending PRACK for first one, an additional nuance is that it is also = required to=20 queue up provisionals even after the first is PRACKed and send them one = at a=20 time, as the PRACK for each is received.
If this were not done, then the PRACKS may be = received out=20 of sequence and mess up the CSeq check for requests received = at the=20 UAS.
Then the UAS will futilely continue = to retransmit the=20 provisionals with no hope of ever matching the PRACKS that were = returned a=20 500 response due to out-of-sequence receipt.

From: Rohan Mahy = [mailto:rohan.mahy@gmail.com]=20
Sent: Wednesday, March 08, 2006 5:51 PM
To: = Jonathan=20 Rosenberg (jdrosen)
Cc: IETF SIP List
Subject: Re: = [Sip] The=20 Problem with PRACK

Hi,

A things about PRACK come immediately to mind that = are a=20 pain to implement:

1) The UAS has to queue provisionals until it = receives=20 a PRACK for the first provisional.  This is due to RSeq starting at = an=20 arbitrary value instead of just starting at 1.  This is probably = the=20 simplest to fix, by just requiring the UAC to always start with a RSeq = of 1.=20

2) Multiple unacknowledged provisionals can be in flight at the = same=20 time.  We could potentially eliminate this requirement by = acknowledging the=20 current status instead of the whole history.  In other words, when = the UAS=20 sends a new reliable provisional, it decides which (if any) of the = previously=20 sent provisionals are still relevant and sends all of them (as sipfrags = or=20 something) as a single reliable request.

3) If you "answer" and = want to=20 deliver a 200 OK, you have to queue it and wait if you are waiting for a = PRACK=20 to an offer or answer. Keeping track of when you can send the 200 would = be=20 easier if we did something like I recommend in #2. 

4) Even = for an=20 acknowledged provisional, you still have to retransmit approximately = every=20 minute (I forget exactly) to prevent old proxies from deleting state for = your=20 transaction.  This is one of those minor annoyances that is = *almost*=20 operationally irrelevant, and unlikely to not get coded.  My = proposal for=20 simplification is to retransmit the latest reliable provisional in = exactly the=20 same way that the UAS retransmits unreliable provisionals.  Who = cares if=20 there is an extra message or two for a call with 1 minute + post-answer = delay?=20

5) I would deprecate the PRACK/200 (PRACK) offer/answer = exchange. =20 I talked Jonathan into this, and I've been sorry I did ever since.  = My=20 apologies to everyone for making a bad decision.

Hope this=20 helps.
thanks,
-rohan

On 3/7/06, Jonathan=20 Rosenberg <jdrosen@cisco.com>=20 wrote:=20
At=20 the last IETF, there was a lot of discussion and argument = around
PRACK. The=20 spark of this debate was the ICE specification, which had
words in = it=20 requiring the usage of PRACK and UPDATE in order to work
with early = media.=20 There was strong pushback from many implementors that
anything = requiring=20 PRACK is unacceptable. Rohan put up a slide (IIRC)
that showed the = state=20 machine in his implementation resulting from
PRACK, and it was not=20 pretty.

So, I'd like to discuss exactly what IS the problem = with PRACK?=20 There
are really two pieces of state machinery in play here. One = piece is=20 the
complication that PRACK introduces into the offer/answer model. = With
PRACK, you can now get a final answer in the 18x, and then = send a=20 new
offer in UPDATE, or even in PRACK itself. Another piece is the=20 state
machinery with the retransmissions itself - correlating the = PRACK=20 with a
particular reliable provisional response and causing it to=20 stop.

In a chat with Flemming today, he suggested in interested = remedy=20 to our
PRACK dilemma. Why not revise PRACK so that you can't send = an offer=20 or
answer with it; it has no impact on the set of allowed O/A=20 exchanges
defined by RFC 3261. I'm not sure if that would = consequently=20 break the
preconditions mechanism, but maybe there are some kind of = offer/answer
limitations that would simplify things.

So, = this is one=20 idea. I'd like for people who have complained about
PRACK = implementations=20 to speak up and indicate what exactly makes it so
complicated for=20 them.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg,=20 = Ph.D.           &n= bsp;      =20 600 Lanidex Plaza
Cisco=20 = Fellow           &= nbsp;           &n= bsp;          =20 Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com   =             &= nbsp;           &n= bsp;  FAX:  =20 (973) 952-5050
http://www.jdrosen.net  &nb= sp;           &nbs= p;         =20 PHONE: (973) 952-5000
http://www.cisco.com

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

------_=_NextPart_001_01C64767.1CCF841A-- --===============1209664257== 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 --===============1209664257==-- From sip-bounces@ietf.org Tue Mar 14 08:01:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ98B-00054G-1O; Tue, 14 Mar 2006 08:00:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ987-00053b-R0 for sip@ietf.org; Tue, 14 Mar 2006 08:00:04 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ987-0008RM-4A for sip@ietf.org; Tue, 14 Mar 2006 08:00:03 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2A94C4F0001; Tue, 14 Mar 2006 13:59:31 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 13:59:30 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 13:59:30 +0100 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] The Problem with PRACK Date: Tue, 14 Mar 2006 13:59:30 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B4F@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDCgVGdfM6J4JZQ7WmeM0st+uMPgEW/zUg From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" , "Brett Tate" X-OriginalArrivalTime: 14 Mar 2006 12:59:30.0487 (UTC) FILETIME=[22093470:01C64767] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 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, An answer can always be sent in the ACK, but the problem is if we want to send it earlier. I also agree that if a device does not support an offer in a PRACK it's a bug. HOWEVER, the standard does not specify how an offer in a PRACK is rejected. This has been discussed before, and one possible solution was that the 200 OK would not contain an SDP, and that would mean the offer was rejected. That is not specified behavior, however. Regards, Christer =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 9. maaliskuuta 2006 1:43 To: Brett Tate Cc: 'IETF SIP List' Subject: Re: [Sip] The Problem with PRACK Brett Tate wrote: >>So, I'd like to discuss exactly what IS the problem with PRACK? There=20 >>are really two pieces of state machinery in play here. One piece is=20 >>the complication that PRACK introduces into the offer/answer model.=20 >>With PRACK, you can now get a final answer in the 18x, and then send a >>new offer in UPDATE, or even in PRACK itself. >=20 >=20 > An offer within the prack is a pain and potentially a little under=20 > specified. >=20 > One problem is that some devices don't support receiving prack with an > offer. There are lots of things that some devices don't support. We call those cases BUGS. Which devices are those? > Thus the sender needs to handle PRACK 200 without SDP and handle a=20 > failure response because of the sdp. Are you suggesting that it is *legal* to: - support PRACK - not support PRACK with sdp? I don't think that is valid. Prack use is enabled via the 100rel option. I'm pretty sure that option comes with the whole boat. > And if the UAS does not accept the > offer, some vendors return 488/606 type responses; others return 200=20 > without SDP. >=20 > I prefer removing ability for prack to contain an offer. However=20 > leaving it is ok if vendors who send it can deal with the typical interop problems. You only want to remove ability for it to contain an offer, but allow it to contain an answer? Or remove support for both offer and answer? As I noted in earlier reply, if we were to do that, then how do you answer an offer that comes in a reliable provisional response? Any change in this stuff has backward compatibility issues. It would require use of new option tags, and even more complex support than the existing situation does. Paul >>Another piece is the state machinery with the retransmissions itself - >>correlating the PRACK with a particular reliable provisional response=20 >>and causing it to stop. >=20 >=20 > I'm not aware of this being very complicated. >=20 >=20 >=20 >>Why not revise PRACK so that you can't send an=20 >>offer or answer with it; it has no impact on the=20 >>set of allowed O/A exchanges defined by RFC 3261.=20 >>I'm not sure if that would consequently break the=20 >>preconditions mechanism, but maybe there are some=20 >>kind of offer/answer limitations that would simplify=20 >>things. >=20 >=20 > Answer within prack is needed unless willing to allow subsequent different > offer from the uas (UPDATE; and maybe other 18x and 2xx) to still override > first 18x offer. >=20 >=20 >=20 >>So, this is one idea. I'd like for people who have=20 >>complained about PRACK implementations to speak up=20 >>and indicate what exactly makes it so complicated=20 >>for them. >=20 >=20 > It isn't complicated. It is just a matter of getting it implemented and > deployed; and dealing with the various interoperability pains. (BTW > draft-sawada-sipping-sip-offeranswer has been a good reference for answering > many of the common questions about offer/answer within sip; hopefully the > draft gets adopted by sipping or sip.) >=20 > One reason devices don't (or quit) supporting 100rel was because of the > SHOULDs/MUSTs related to offer/answer. Another reason is because of the > extra messaging. >=20 > And because subsequent SDPs sent within INVITE 18x/2xx no longer have > precedent over the prior SDP, interoperability is a pain. The UAS now > requires rfc3311 and rfc3262 support, and/or ability for UAC to finally > support forking interactions (18x/2xx with different tags). >=20 >=20 > The following are a few random things currently not resolved and/or clearly > specified. Others are just some random thoughts/rants concerning > interoperability. >=20 > 1) Dealing with 18x offer/answer rules with timer c is under specified. > Should the periodic 18x contain an SDP again? And if so, which one if > another sent in UPDATE, PRACK, or their responses? >=20 > 2) RFC3261 discusses possibility of sending SDP again in INVITE 200 > response. And it says it must be same as prior 18x SDP. However I assume > if some send it (for backwards compatibility reasons), UAS should send the > latest correct SDP (if different SDP sent in UPDATE, PRACK response, or > UPDATE response). >=20 > 3) A forking proxy currently has no mechanism to indicate to uac when a > branch has been terminated. Thus the UAC is currently unable to easily > determine which early dialogs have disappeared. Hopefully this > functionality will get resolved/included within herfp or another draft. >=20 > 4) Concerning UPDATE and SDP, some vendors think SDP is required. And some > vendors can't handle receiving the 504 response mentioned within rfc3311 > without releasing the call. >=20 > 5) "audit" with sdp is pain (especially when prior "answer" becomes "offer" > within audit). This is mainly just a pain to B2BUAs. Hopefully more > devices will start correctly support receiving UPDATE without SDP. >=20 > 6) Some devices still do not support forking proxy interactions very well > because some B2BUAs reduced the need. And because of all the current > offer/answer rules, devices expecting correct offer/answer behavior need to > interact well with forking proxies. I mention this because if a UAS needs > to update the SDP and can't (because of offer/answer rules, etcetera), it > might act like forking occurred and send a 18x/2xx with a different tag. >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 08:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ99w-0006p1-7P; Tue, 14 Mar 2006 08:01:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ99t-0006n3-Fy for sip@ietf.org; Tue, 14 Mar 2006 08:01:53 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ99s-00005L-Kt for sip@ietf.org; Tue, 14 Mar 2006 08:01:53 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0F1DC631; Tue, 14 Mar 2006 14:01:52 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 14:01:51 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 14:01:51 +0100 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] The Problem with PRACK Date: Tue, 14 Mar 2006 14:01:50 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B50@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDlpU8GeRLtCaDTfqzBZ0jmUZapgD0KFkQ From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" , "Prince A P" X-OriginalArrivalTime: 14 Mar 2006 13:01:51.0349 (UTC) FILETIME=[75FF0A50:01C64767] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: da41e01217ab11ad82db577473e913ae 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 BELIEVE that the reason for allowing offer/answer in PRACK was the precondition mechansim, but there are probably people who know more than me about that. Regards, Christer =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 9. maaliskuuta 2006 18:29 To: Prince A P Cc: sip@ietf.org Subject: Re: [Sip] The Problem with PRACK Prince A P wrote: > Hi, > =20 > If the 3262 is only for Reliability of Provisional responses, Why=20 > should it mandate Offer-Answer completion? > Was there any rationale behind clubbing Reliability with Offer-Answer? I wasn't there when that was done, so I can't speak to the actual motives of those who were. But note that offer/answer has no mechanism of its own - it must be associated with some messages in the signaling system. Reliable provisionals, without sdp in the PRACK, are sufficient for early completion of the offer/answer exchange when the offer is in the invite. But that isn't sufficient to achieve early completion of offer/answer when there is no offer in the invite. In that case the offer is in the reliable provisional, and the obvious place for the answer is in the PRACK. That seems to be reasonable justification for involving PRACK in offer/answer. Allowing an offer in PRACK is less motivated. Essentially the same thing can be done using UPDATE. I can speculate on some reasons for allowing PRACK to be used for this: - done before UPDATE was invented - efficiency - the prack is required anyway - prack already needs to carry an answer, why not an offer Paul > =20 > rgds, > Prince >=20 >=20 > =20 >=20 > To: "Samir Srivastava" < samirsr@nortel.com > >, "Paul Kyzivat" >, "Francois Audet" < > audet@nortel.com > > From: "Samir Srivastava" < samirsr@nortel.com > > > Date: 03/09/2006 01:18PM > cc: IETF SIP List > > Subject: RE: [Sip] The Problem with PRACK >=20 > We can do it, by adding more logic / header. UAS knows about all the > hops by complete via header set inspection. When sending 1xx, it > need to > indicate in this new header to be defined. Is it worth > defining this ? >=20 >=20 > Thx > Samir >=20 > -----Original Message----- > From: Srivastava, Samir [SC100:8826:EXCH] > Sent: Wednesday, March 08, 2006 11:19 PM > To: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH] > Cc: IETF SIP List > Subject: RE: [Sip] The Problem with PRACK >=20 > We can do for SIPS only. >=20 > Thx > Samir >=20 > -----Original Message----- > From: Paul Kyzivat [ mailto:pkyzivat@cisco.com] > Sent: Wednesday, March 08, 2006 7:29 PM > To: Audet, Francois [SC100:3055:EXCH] > Cc: IETF SIP List > Subject: Re: [Sip] The Problem with PRACK >=20 >=20 >=20 > Francois Audet wrote: > > I'm ok with the suggestion to deprecate using PRACK for > Offer/Answer. > > > > While we are at it, why not go for deprecating the use PRACK > > altogether when TCP transport is used? >=20 > Explain to me again how you would know that reliable transport > is used > end to end? >=20 > Paul >=20 > > On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: > > > >> Hi, > >> > >> A things about PRACK come immediately to mind that are a pain to > >> implement: > >> > >> 1) The UAS has to queue provisionals until it receives a > PRACK for > >> the first provisional. This is due to RSeq starting at an > arbitrary > >> value instead of just starting at 1. This is probably the > simplest > >> to fix, by just requiring the UAC to always start with a > RSeq of 1. > >> > >> 2) Multiple unacknowledged provisionals can be in flight at > the same > >> time. We could potentially eliminate this requirement by > >> acknowledging the current status instead of the whole > history. In > >> other words, when the UAS sends a new reliable provisional, it > >> decides which (if any) of the previously sent provisionals > are still > >> relevant and sends all of them (as sipfrags or something) as > a single >=20 > >> reliable request. > >> > >> 3) If you "answer" and want to deliver a 200 OK, you have to > queue it >=20 > >> and wait if you are waiting for a PRACK to an offer or answer. > >> Keeping track of when you can send the 200 would be easier > if we did > >> something like I recommend in #2. > >> > >> 4) Even for an acknowledged provisional, you still have to > retransmit >=20 > >> approximately every minute (I forget exactly) to prevent old > proxies > >> from deleting state for your transaction. This is one of > those minor >=20 > >> annoyances that is *almost* operationally irrelevant, and > unlikely to >=20 > >> not get coded. My proposal for simplification is to > retransmit the > >> latest reliable provisional in exactly the same way that the > UAS > >> retransmits unreliable provisionals. Who cares if there is > an extra > >> message or two for a call with 1 minute + post-answer delay? > >> > >> 5) I would deprecate the PRACK/200 (PRACK) offer/answer > exchange. I > >> talked Jonathan into this, and I've been sorry I did ever > since. My > >> apologies to everyone for making a bad decision. > >> > >> Hope this helps. > >> thanks, > >> -rohan > >> > >> On 3/7/06, *Jonathan Rosenberg* < jdrosen@cisco.com > > >> > wrote: > >> > >> At the last IETF, there was a lot of discussion and > argument > around > >> PRACK. The spark of this debate was the ICE > specification, which > had > >> words in it requiring the usage of PRACK and UPDATE in > order to > work > >> with early media. There was strong pushback from many > implementors > >> that > >> anything requiring PRACK is unacceptable. Rohan put up a > slide > (IIRC) > >> that showed the state machine in his implementation > resulting > from > >> PRACK, and it was not pretty. > >> > >> So, I'd like to discuss exactly what IS the problem with > PRACK? > There > >> are really two pieces of state machinery in play here. > One piece > >> is the > >> complication that PRACK introduces into the offer/answer > model. > With > >> PRACK, you can now get a final answer in the 18x, and > then send a > new > >> offer in UPDATE, or even in PRACK itself. Another piece > is the > state > >> machinery with the retransmissions itself - correlating > the PRACK > >> with a > >> particular reliable provisional response and causing it > to stop. > >> > >> In a chat with Flemming today, he suggested in > interested remedy > >> to our > >> PRACK dilemma. Why not revise PRACK so that you can't > send an > offer or > >> answer with it; it has no impact on the set of allowed O/A > exchanges > >> defined by RFC 3261. I'm not sure if that would > consequently > break the > >> preconditions mechanism, but maybe there are some kind of > offer/answer > >> limitations that would simplify things. > >> > >> So, this is one idea. I'd like for people who have > complained > about > >> PRACK implementations to speak up and indicate what > exactly makes > >> it so > >> complicated for them. > >> > >> Thanks, > >> Jonathan R. > >> -- > >> Jonathan D. Rosenberg, Ph.D. 600 > Lanidex Plaza > >> Cisco Fellow =20 > Parsippany, NJ > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com > >> < mailto:jdrosen@cisco.com> > FAX: =20 > >> (973) 952-5050 > >> http://www.jdrosen.net > PHONE: (973) > 952-5000 > >> http://www.cisco.com > >> > >> _______________________________________________ > >> 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 < > mailto:sipping@ietf.org> for new > >> developments on the application of sip > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use > >> sip-implementors@cs.columbia.edu > > >> for questions on > current > >> sip Use sipping@ietf.org < > mailto:sipping@ietf.org> for new > >> developments on the application of sip > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu > for questions on > current sip > Use sipping@ietf.org for new > developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu > for questions on > current sip > Use sipping@ietf.org for new > developments on the application of sip >=20 >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 08:43:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ9m2-0008K7-UJ; Tue, 14 Mar 2006 08:41:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ9m1-0008K2-Qz for sip@ietf.org; Tue, 14 Mar 2006 08:41:17 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ9m0-0001QC-KP for sip@ietf.org; Tue, 14 Mar 2006 08:41:17 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k2EDf6cD074821; Tue, 14 Mar 2006 08:41:15 -0500 (EST) From: "Brett Tate" To: "'Juha Heinanen'" Subject: RE: [Sip] The Problem with PRACK Date: Tue, 14 Mar 2006 08:42:11 -0500 Message-ID: <000901c6476d$1be88b30$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <17430.47090.634650.930408@rautu.tutpro.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 > why do you use prack rather than tcp or just udp=20 > with retransmissions in case 200 OK gets lost? As currently specified (rfc3261 section 13.2.1) for offer/answer, a 18x = with SDP sent over a reliable transport without use of 100rel is not = considered an answer. Thus if 100rel is not used, UPDATE cannot carry a related = offer since there is still an outstanding offer without an official answer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 09:01:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJA3i-0001kf-1v; Tue, 14 Mar 2006 08:59:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJA3g-0001jF-A5 for sip@ietf.org; Tue, 14 Mar 2006 08:59:32 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJA3c-0001sB-UK for sip@ietf.org; Tue, 14 Mar 2006 08:59:32 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 9526F14040C; Tue, 14 Mar 2006 15:59:27 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 5C30A140407; Tue, 14 Mar 2006 15:59:06 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 02B39F027E; Tue, 14 Mar 2006 15:59:24 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17430.52284.197018.217222@rautu.tutpro.com> Date: Tue, 14 Mar 2006 15:59:24 +0200 From: Juha Heinanen To: "Brett Tate" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <000901c6476d$1be88b30$2c28a8c0@brett1> References: <17430.47090.634650.930408@rautu.tutpro.com> <000901c6476d$1be88b30$2c28a8c0@brett1> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Brett Tate writes: > As currently specified (rfc3261 section 13.2.1) for offer/answer, a 18x with > SDP sent over a reliable transport without use of 100rel is not considered > an answer. Thus if 100rel is not used, UPDATE cannot carry a related offer > since there is still an outstanding offer without an official answer. if offer in invite is not acceptable, why not reject it and tell what kind of offer would have been acceptable? -- 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 Mar 14 09:17:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJAJT-00011K-K6; Tue, 14 Mar 2006 09:15:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJAJR-0000w5-9b for sip@ietf.org; Tue, 14 Mar 2006 09:15:49 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJAJQ-0002O8-31 for sip@ietf.org; Tue, 14 Mar 2006 09:15:49 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k2EEFha5077646; Tue, 14 Mar 2006 09:15:47 -0500 (EST) From: "Brett Tate" To: "'Juha Heinanen'" Subject: RE: [Sip] The Problem with PRACK Date: Tue, 14 Mar 2006 09:16:48 -0500 Message-ID: <000c01c64771$eed52360$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <17430.52284.197018.217222@rautu.tutpro.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 currently specified (rfc3261 section 13.2.1) for=20 > > offer/answer, a 18x with SDP sent over a reliable=20 > > transport without use of 100rel is not considered =20 > > an answer. Thus if 100rel is not used, UPDATE cannot=20 > > carry a related offer since there is still an=20 > > outstanding offer without an official answer. >=20 > if offer in invite is not acceptable, why not reject it=20 > and tell what kind of offer would have been acceptable? My comment has nothing to do with acceptability of the SDP. =20 My comment is to indicate that reliability of transport currently has nothing to do with "reliability" related to offer/answer rules. Thus = 100rel is currently still required on reliable transports for offer/answer = reasons. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 09:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJATe-0005aI-En; Tue, 14 Mar 2006 09:26:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJATc-0005aD-A5 for sip@ietf.org; Tue, 14 Mar 2006 09:26:20 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJATa-0002mK-VW for sip@ietf.org; Tue, 14 Mar 2006 09:26:20 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2EEQH0u007654; Tue, 14 Mar 2006 08:26:17 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2EEQGV28745; Tue, 14 Mar 2006 08:26:17 -0600 (CST) Message-ID: <4416D284.3000203@lucent.com> Date: Tue, 14 Mar 2006 08:26:12 -0600 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: Cullen Jennings Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 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="===============0943383336==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0943383336== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030609090303050000060005" This is a cryptographically signed message in MIME format. --------------ms030609090303050000060005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > I know of several proxies today that will support multiple domains. However, > all the ones that I have seen that do TLS require a separate port for each > domain. That is because the TLS extensions to specify the domain in the > handshake are not that widely used yet. True; for those who are using OpenSSL, there is a patch to OpenSSL to support rfc3546. Information for the patch is at: http://www.mail-archive.com/openssl-dev@openssl.org/msg20260.html. But I do not think it has made it into the last stable release for OpenSSL (0.9.8). - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms030609090303050000060005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUFrom sip-bounces@ietf.org Tue Mar 14 09:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJATe-0005aI-En; Tue, 14 Mar 2006 09:26:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJATc-0005aD-A5 for sip@ietf.org; Tue, 14 Mar 2006 09:26:20 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJATa-0002mK-VW for sip@ietf.org; Tue, 14 Mar 2006 09:26:20 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2EEQH0u007654; Tue, 14 Mar 2006 08:26:17 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2EEQGV28745; Tue, 14 Mar 2006 08:26:17 -0600 (CST) Message-ID: <4416D284.3000203@lucent.com> Date: Tue, 14 Mar 2006 08:26:12 -0600 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: Cullen Jennings Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 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="===============0943383336==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0943383336== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030609090303050000060005" This is a cryptographically signed message in MIME format. --------------ms030609090303050000060005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > I know of several proxies today that will support multiple domains. However, > all the ones that I have seen that do TLS require a separate port for each > domain. That is because the TLS extensions to specify the domain in the > handshake are not that widely used yet. True; for those who are using OpenSSL, there is a patch to OpenSSL to support rfc3546. Information for the patch is at: http://www.mail-archive.com/openssl-dev@openssl.org/msg20260.html. But I do not think it has made it into the last stable release for OpenSSL (0.9.8). - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms030609090303050000060005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXAyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w06Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMTQxNDI2MTNaMCMGCSqGSIb3DQEJ BDEWBBQBJPfn6R0CN7abvW5C/AH4Hr+N9TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAleAtK1Wpd95H1S7USZNfVfRBggztdxyC/A/1OiSp77bY+a8FQ4JL OS+z17RMOTB+4LRiHY85xj3AdgS0mywSFNlJYEpdJVGG7+d2OCc1wkjCvV+6R2AazEagqi6y S2kZ+V0VTVAk8thryJIPlCKvy9G/zz/9J2yNCfaiTYrWlp8AAAAAAAA= --------------ms030609090303050000060005-- --===============0943383336== 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 --===============0943383336==-- From sip-bounces@ietf.org Tue Mar 14 09:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJATk-0005hp-U0; Tue, 14 Mar 2006 09:26:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJATj-0005hk-NU for sip@ietf.org; Tue, 14 Mar 2006 09:26:27 -0500 Received: from nproxy.gmail.com ([64.233.182.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJATi-0002mT-En for sip@ietf.org; Tue, 14 Mar 2006 09:26:27 -0500 Received: by nproxy.gmail.com with SMTP id d4so1037616nfe for ; Tue, 14 Mar 2006 06:26:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=oiYhqFNvk4VClXsDXbKIK3PVdL0n6e1zOeu+AmLnaO0sLnBNk2Uin5MoBeTC2HwC4BlbD2DzwtU3PDT/WL2YIoTWF8045gcdRtCnXNHnxPAqYopgm3Fq8qHU4Mi8ujw9+jNQXY4AiHGN5mYg83cCuHWu7iDjFHmhRxgAAdhG53s= Received: by 10.49.72.7 with SMTP id z7mr2292504nfk; Tue, 14 Mar 2006 06:26:25 -0800 (PST) Received: by 10.49.35.18 with HTTP; Tue, 14 Mar 2006 06:26:25 -0800 (PST) Message-ID: <52db68bc0603140626j20ba9e8am26407d310d3620c3@mail.gmail.com> Date: Tue, 14 Mar 2006 19:56:25 +0530 From: Sudhir To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Sip] Query on SIP Torture test X-BeenThere: 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="===============1016868967==" Errors-To: sip-bounces@ietf.org --===============1016868967== Content-Type: multipart/alternative; boundary="----=_Part_2132_15355565.1142346385505" ------=_Part_2132_15355565.1142346385505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpJIHdvdWxkIGxpa2UgdG8ga25vdyByZWdhcmRpbmcgRW5jb2RlZCByZWZlcmVuY2UgbWVz c2FnZXMgb2YgU0lQIFRvcnR1cmUKVGVzdHMgZHJhZnQuIFdoZW4gSW0gdHJ5aW5nIHRvIERlY29k ZSB3aXRoIGJhc2U2NCB1dGlsaXR5IGl0IGlzIGdpdmluZyBqdW5rCmNoYXJhY3RlcnMuIENvdWxk IEkga25vdyB3aGF0IHdvdWxkIGJlIHRoZSBjb3JyZWN0IGFwcG9yYWNoIHRvIGRlY29kZSB0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMTQxNDI2MTNaMCMGCSqGSIb3DQEJ BDEWBBQBJPfn6R0CN7abvW5C/AH4Hr+N9TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAleAtK1Wpd95H1S7USZNfVfRBggztdxyC/A/1OiSp77bY+a8FQ4JL OS+z17RMOTB+4LRiHY85xj3AdgS0mywSFNlJYEpdJVGG7+d2OCc1wkjCvV+6R2AazEagqi6y S2kZ+V0VTVAk8thryJIPlCKvy9G/zz/9J2yNCfaiTYrWlp8AAAAAAAA= --------------ms030609090303050000060005-- --===============0943383336== 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 --===============0943383336==-- From sip-bounces@ietf.org Tue Mar 14 09:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJATk-0005hp-U0; Tue, 14 Mar 2006 09:26:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJATj-0005hk-NU for sip@ietf.org; Tue, 14 Mar 2006 09:26:27 -0500 Received: from nproxy.gmail.com ([64.233.182.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJATi-0002mT-En for sip@ietf.org; Tue, 14 Mar 2006 09:26:27 -0500 Received: by nproxy.gmail.com with SMTP id d4so1037616nfe for ; Tue, 14 Mar 2006 06:26:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=oiYhqFNvk4VClXsDXbKIK3PVdL0n6e1zOeu+AmLnaO0sLnBNk2Uin5MoBeTC2HwC4BlbD2DzwtU3PDT/WL2YIoTWF8045gcdRtCnXNHnxPAqYopgm3Fq8qHU4Mi8ujw9+jNQXY4AiHGN5mYg83cCuHWu7iDjFHmhRxgAAdhG53s= Received: by 10.49.72.7 with SMTP id z7mr2292504nfk; Tue, 14 Mar 2006 06:26:25 -0800 (PST) Received: by 10.49.35.18 with HTTP; Tue, 14 Mar 2006 06:26:25 -0800 (PST) Message-ID: <52db68bc0603140626j20ba9e8am26407d310d3620c3@mail.gmail.com> Date: Tue, 14 Mar 2006 19:56:25 +0530 From: Sudhir To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Sip] Query on SIP Torture test X-BeenThere: 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="===============1016868967==" Errors-To: sip-bounces@ietf.org --===============1016868967== Content-Type: multipart/alternative; boundary="----=_Part_2132_15355565.1142346385505" ------=_Part_2132_15355565.1142346385505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpJIHdvdWxkIGxpa2UgdG8ga25vdyByZWdhcmRpbmcgRW5jb2RlZCByZWZlcmVuY2UgbWVz c2FnZXMgb2YgU0lQIFRvcnR1cmUKVGVzdHMgZHJhZnQuIFdoZW4gSW0gdHJ5aW5nIHRvIERlY29k ZSB3aXRoIGJhc2U2NCB1dGlsaXR5IGl0IGlzIGdpdmluZyBqdW5rCmNoYXJhY3RlcnMuIENvdWxk IEkga25vdyB3aGF0IHdvdWxkIGJlIHRoZSBjb3JyZWN0IGFwcG9yYWNoIHRvIGRlY29kZSB0aGVz ZQptZXNzYWdlcy4KCkluZGVlZCwgSSBoYXZlIHRyaWVkIG91dCB3aXRoIHRoZSBQRVJMIHNjcmlw dCBhbmQgb3RoZXIgdG9vbHMgd2hpY2ggdGhlCmZvbGxvd2luZyBpbnB1dCggc29tZSBwYXJ0IG9m IHRoZSBtZXNzYWdlIHdoaWNoIGlzIGluIEFwcGVuZGl4IEEgKFNJUAp0b3J0dXJlIHRlc3RzKS4K CmlucHV0OgpINHNJQUVEd2NFTUNBK3hkVzJ6YzJIbTJuZXhORzZVTjNMUkYwUWZhaUtKZHl4d2Ru a01PaHlPUFZySXQKICAgMjdJdDIydGR2SFlUZU04TUR6V2M0WkFqa3FPUnZLMmJiSUFBZWRtSHRF SFJkbHZrb1VDTEZBalNseUxGCiAgIDlySlBMWW9XclRkQWc2SkZId3AwaSs1RDBTSW9FQVFGdWoy SG5BdUg1R2dvVzNQeG1nY2F6WVUvYjRmLwogICAvLzNYYzA0UnE5aXBrMUpHeGU2eElUVkFXMVlV dlhjNUsKCm91dHB1dDoKQHBDAgNdW2x5TRsK3LRFB9qIXRwdQw4jVi3bsi1rXXYTeCAPNSNsCgp0 aGFua3MgaW4gYWR2YW5jZQoKYmVzdCByZWdhcmRzCnN1ZGhpcgo= ------=_Part_2132_15355565.1142346385505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj4KPHA+SGksPC9wPgo8cD5JIHdvdWxkIGxpa2UgdG8ga25vdyByZWdhcmRpbmcgRW5jb2Rl ZCByZWZlcmVuY2UgbWVzc2FnZXMgb2YgU0lQIFRvcnR1cmUgVGVzdHMgZHJhZnQuIFdoZW4gSW0g dHJ5aW5nIHRvIERlY29kZSB3aXRoIGJhc2U2NCB1dGlsaXR5IGl0IGlzIGdpdmluZyBqdW5rIGNo YXJhY3RlcnMuIENvdWxkIEkga25vdyB3aGF0IHdvdWxkIGJlIHRoZSBjb3JyZWN0IGFwcG9yYWNo IHRvIGRlY29kZSB0aGVzZSBtZXNzYWdlcy4gCjwvcD4KPHA+SW5kZWVkLCBJIGhhdmUgdHJpZWQg b3V0IHdpdGggdGhlIFBFUkwgc2NyaXB0IGFuZCBvdGhlciB0b29scyB3aGljaCB0aGUgZm9sbG93 aW5nIGlucHV0KCBzb21lIHBhcnQgb2YgdGhlIG1lc3NhZ2Ugd2hpY2ggaXMgaW4gQXBwZW5kaXgg QSAoU0lQIHRvcnR1cmUgdGVzdHMpLiZuYnNwOyA8L3A+CjxwPmlucHV0Ojxicj5INHNJQUVEd2NF TUNBK3hkVzJ6YzJIbTJuZXhORzZVTjNMUkYwUWZhaUtKZHl4d2Rua01PaHlPUFZySXQ8YnI+Jm5i c3A7Jm5ic3A7IDI3SXQyMnRkdkhZVGVNOE1EeldjNFpBamtxT1J2SzJiYklBQWVkbUh0RUhSZGx2 a29VQ0xGQWpTbHlMRjxicj4mbmJzcDsmbmJzcDsgOXJKUExZb1dyVGRBZzZKRkh3cDBpKzVEMFNJ b0VBUUZ1ajJIbkF1SDVHZ29XM1B4bWdjYXpZVS9iNGYvPGJyPiZuYnNwOyZuYnNwOyAvLzNYYzA0 UnE5aXBrMUpHeGU2eElUVkFXMVlVdlhjNUsgCjwvcD4KPHA+b3V0cHV0Ojxicj5AcEMCA11bbHlN Gzxicj7ctEUH2ohdHB1DDiNWLduyLWtddhN4IA81I2w8L3A+CjxwPnRoYW5rcyBpbiBhZHZhbmNl PC9wPgo8cD5iZXN0IHJlZ2FyZHM8YnI+c3VkaGlyPC9wPjwvZGl2Pgo= ------=_Part_2132_15355565.1142346385505-- --===============1016868967== 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 --===============1016868967==-- aGVz ZQptZXNzYWdlcy4KCkluZGVlZCwgSSBoYXZlIHRyaWVkIG91dCB3aXRoIHRoZSBQRVJMIHNjcmlw dCBhbmQgb3RoZXIgdG9vbHMgd2hpY2ggdGhlCmZvbGxvd2luZyBpbnB1dCggc29tZSBwYXJ0IG9m IHRoZSBtZXNzYWdlIHdoaWNoIGlzIGluIEFwcGVuZGl4IEEgKFNJUAp0b3J0dXJlIHRlc3RzKS4K CmlucHV0OgpINHNJQUVEd2NFTUNBK3hkVzJ6YzJIbTJuZXhORzZVTjNMUkYwUWZhaUtKZHl4d2Ru a01PaHlPUFZySXQKICAgMjdJdDIydGR2SFlUZU04TUR6V2M0WkFqa3FPUnZLMmJiSUFBZWRtSHRF SFJkbHZrb1VDTEZBalNseUxGCiAgIDlySlBMWW9XclRkQWc2SkZId3AwaSs1RDBTSW9FQVFGdWoy SG5BdUg1R2dvVzNQeG1nY2F6WVUvYjRmLwogICAvLzNYYzA0UnE5aXBrMUpHeGU2eElUVkFXMVlV dlhjNUsKCm91dHB1dDoKQHBDAgNdW2x5TRsK3LRFB9qIXRwdQw4jVi3bsi1rXXYTeCAPNSNsCgp0 aGFua3MgaW4gYWR2YW5jZQoKYmVzdCByZWdhcmRzCnN1ZGhpcgo= ------=_Part_2132_15355565.1142346385505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj4KPHA+SGksPC9wPgo8cD5JIHdvdWxkIGxpa2UgdG8ga25vdyByZWdhcmRpbmcgRW5jb2Rl ZCByZWZlcmVuY2UgbWVzc2FnZXMgb2YgU0lQIFRvcnR1cmUgVGVzdHMgZHJhZnQuIFdoZW4gSW0g dHJ5aW5nIHRvIERlY29kZSB3aXRoIGJhc2U2NCB1dGlsaXR5IGl0IGlzIGdpdmluZyBqdW5rIGNo YXJhY3RlcnMuIENvdWxkIEkga25vdyB3aGF0IHdvdWxkIGJlIHRoZSBjb3JyZWN0IGFwcG9yYWNo IHRvIGRlY29kZSB0aGVzZSBtZXNzYWdlcy4gCjwvcD4KPHA+SW5kZWVkLCBJIGhhdmUgdHJpZWQg b3V0IHdpdGggdGhlIFBFUkwgc2NyaXB0IGFuZCBvdGhlciB0b29scyB3aGljaCB0aGUgZm9sbG93 aW5nIGlucHV0KCBzb21lIHBhcnQgb2YgdGhlIG1lc3NhZ2Ugd2hpY2ggaXMgaW4gQXBwZW5kaXgg QSAoU0lQIHRvcnR1cmUgdGVzdHMpLiZuYnNwOyA8L3A+CjxwPmlucHV0Ojxicj5INHNJQUVEd2NF TUNBK3hkVzJ6YzJIbTJuZXhORzZVTjNMUkYwUWZhaUtKZHl4d2Rua01PaHlPUFZySXQ8YnI+Jm5i c3A7Jm5ic3A7IDI3SXQyMnRkdkhZVGVNOE1EeldjNFpBamtxT1J2SzJiYklBQWVkbUh0RUhSZGx2 a29VQ0xGQWpTbHlMRjxicj4mbmJzcDsmbmJzcDsgOXJKUExZb1dyVGRBZzZKRkh3cDBpKzVEMFNJ b0VBUUZ1ajJIbkF1SDVHZ29XM1B4bWdjYXpZVS9iNGYvPGJyPiZuYnNwOyZuYnNwOyAvLzNYYzA0 UnE5aXBrMUpHeGU2eElUVkFXMVlVdlhjNUsgCjwvcD4KPHA+b3V0cHV0Ojxicj5AcEMCA11bbHlN Gzxicj7ctEUH2ohdHB1DDiNWLduyLWtddhN4IA81I2w8L3A+CjxwPnRoYW5rcyBpbiBhZHZhbmNl PC9wPgo8cD5iZXN0IHJlZ2FyZHM8YnI+c3VkaGlyPC9wPjwvZGl2Pgo= ------=_Part_2132_15355565.1142346385505-- --===============1016868967== 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 --===============1016868967==-- From sip-bounces@ietf.org Tue Mar 14 10:00:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJAyp-0004QX-KR; Tue, 14 Mar 2006 09:58:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJAyo-0004QS-GO for sip@ietf.org; Tue, 14 Mar 2006 09:58:34 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJAym-0003ep-70 for sip@ietf.org; Tue, 14 Mar 2006 09:58:34 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 641577BB; Tue, 14 Mar 2006 15:58:31 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 15:58:31 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 15:58:30 +0100 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] The Problem with PRACK Date: Tue, 14 Mar 2006 15:58:29 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B51@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDlqOrQGOJVrmUTly6shAze7mvMADxu20gAAZ/myA= From: "Christer Holmberg \(JO/LMF\)" To: , , X-OriginalArrivalTime: 14 Mar 2006 14:58:30.0727 (UTC) FILETIME=[C1F35D70:01C64777] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2f0065339d489fe5a2873ea9ad776d1a 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, 3GPP has now also defined procedures where the usage of the precondition mechanism is not mandated. Regards, Christer =20 -----Original Message----- From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 Sent: 14. maaliskuuta 2006 14:09 To: pkyzivat@cisco.com; princeap@gmail.com Cc: sip@ietf.org Subject: RE: [Sip] The Problem with PRACK =20 Hi, >> PRACK dilemma. Why not revise PRACK so that you can't send an offer or=20 >> answer with it; it has no impact on the set of allowed O/A exchanges=20 >> defined by RFC 3261. > In any case, any change like this must be accompanied by a some strategy=20 > for backward compatibility. This seems not so easy. As much as it is fun=20 > to imagine how it might have been done better the first time around, I > suspect that at this point the cure is worse than the disease. I would just like to point out that the session setup specified for 3GPP IMS networks uses preconditions and implicitely assume sending an offer within PRACK. This is done for efficiency reasons like Paul indicated: >Allowing an offer in PRACK is less motivated. Essentially the same=20 >thing can be done using UPDATE. I can speculate on some reasons for=20 >allowing PRACK to be used for this: >- efficiency - the prack is required anyway The 3GPP call setup with preconditions consists of 4 SIP transactions: INVITE, two PRACKs for reliable responses and one UPDATE, covering two to three offer-answer exchanges. All this (performed over long-range radio access) will take considerable amount of time, more than 10 seconds in the worst case. Adding yet another UPDATE transaction to those would make the setup time even longer. This far 3GPP has adopted a strategy to be compliant to IETF specs. However obsoleting PRACK to contain an SDP offer would have a backward compatibility problem towards all 3GPP compliant implementations, whether they would be applied within IMS networks or Internet. Anyway the issue here is that for any transport requiring resource reservation (and preconditions) and providing long RTT, this kind of change would push session setup times to their limits, no more acceptable to average users. Regards, Erkki >-----Original Message----- >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: 09.March.2006 18:29 >To: Prince A P >Cc: sip@ietf.org >Subject: Re: [Sip] The Problem with PRACK > > > >Prince A P wrote: >> Hi, >> =20 >> If the 3262 is only for Reliability of Provisional >responses, Why should >> it mandate Offer-Answer completion? >> Was there any rationale behind clubbing Reliability with >Offer-Answer? > >I wasn't there when that was done, so I can't speak to the actual=20 >motives of those who were. > >But note that offer/answer has no mechanism of its own - it must be=20 >associated with some messages in the signaling system. > >Reliable provisionals, without sdp in the PRACK, are sufficient for=20 >early completion of the offer/answer exchange when the offer is in the=20 >invite. But that isn't sufficient to achieve early completion of=20 >offer/answer when there is no offer in the invite. In that case the=20 >offer is in the reliable provisional, and the obvious place for the=20 >answer is in the PRACK. That seems to be reasonable justification for=20 >involving PRACK in offer/answer. > >Allowing an offer in PRACK is less motivated. Essentially the same=20 >thing can be done using UPDATE. I can speculate on some reasons for=20 >allowing PRACK to be used for this: >- done before UPDATE was invented >- efficiency - the prack is required anyway >- prack already needs to carry an answer, why not an offer > > Paul > >> =20 >> rgds, >> Prince >>=20 >>=20 >> =20 >>=20 >> To: "Samir Srivastava" < samirsr@nortel.com >> >, "Paul Kyzivat"=20 >> >, "Francois Audet" < >> audet@nortel.com > >> From: "Samir Srivastava" < samirsr@nortel.com >> > >> Date: 03/09/2006 01:18PM >> cc: IETF SIP List > >> Subject: RE: [Sip] The Problem with PRACK >>=20 >> We can do it, by adding more logic / header. UAS >knows about all the >> hops by complete via header set inspection. When >sending 1xx, it >> need to >> indicate in this new header to be defined. Is it worth >> defining this ? >>=20 >>=20 >> Thx >> Samir >>=20 >> -----Original Message----- >> From: Srivastava, Samir [SC100:8826:EXCH] >> Sent: Wednesday, March 08, 2006 11:19 PM >> To: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH] >> Cc: IETF SIP List >> Subject: RE: [Sip] The Problem with PRACK >>=20 >> We can do for SIPS only. >>=20 >> Thx >> Samir >>=20 >> -----Original Message----- >> From: Paul Kyzivat [ mailto:pkyzivat@cisco.com] >> Sent: Wednesday, March 08, 2006 7:29 PM >> To: Audet, Francois [SC100:3055:EXCH] >> Cc: IETF SIP List >> Subject: Re: [Sip] The Problem with PRACK >>=20 >>=20 >>=20 >> Francois Audet wrote: >> > I'm ok with the suggestion to deprecate using PRACK for >> Offer/Answer. >> > >> > While we are at it, why not go for deprecating >the use PRACK >> > altogether when TCP transport is used? >>=20 >> Explain to me again how you would know that reliable >transport >> is used >> end to end? >>=20 >> Paul >>=20 >> > On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: >> > >> >> Hi, >> >> >> >> A things about PRACK come immediately to mind >that are a pain to >> >> implement: >> >> >> >> 1) The UAS has to queue provisionals until it receives a >> PRACK for >> >> the first provisional. This is due to RSeq >starting at an >> arbitrary >> >> value instead of just starting at 1. This is >probably the >> simplest >> >> to fix, by just requiring the UAC to always start with a >> RSeq of 1. >> >> >> >> 2) Multiple unacknowledged provisionals can be >in flight at >> the same >> >> time. We could potentially eliminate this requirement by >> >> acknowledging the current status instead of the whole >> history. In >> >> other words, when the UAS sends a new reliable >provisional, it >> >> decides which (if any) of the previously sent >provisionals >> are still >> >> relevant and sends all of them (as sipfrags or >something) as >> a single >>=20 >> >> reliable request. >> >> >> >> 3) If you "answer" and want to deliver a 200 OK, >you have to >> queue it >>=20 >> >> and wait if you are waiting for a PRACK to an >offer or answer. >> >> Keeping track of when you can send the 200 would >be easier >> if we did >> >> something like I recommend in #2. >> >> >> >> 4) Even for an acknowledged provisional, you >still have to >> retransmit >>=20 >> >> approximately every minute (I forget exactly) to >prevent old >> proxies >> >> from deleting state for your transaction. This is one of >> those minor >>=20 >> >> annoyances that is *almost* operationally irrelevant, and >> unlikely to >>=20 >> >> not get coded. My proposal for simplification is to >> retransmit the >> >> latest reliable provisional in exactly the same >way that the >> UAS >> >> retransmits unreliable provisionals. Who cares >if there is >> an extra >> >> message or two for a call with 1 minute + >post-answer delay? >> >> >> >> 5) I would deprecate the PRACK/200 (PRACK) offer/answer >> exchange. I >> >> talked Jonathan into this, and I've been sorry I did ever >> since. My >> >> apologies to everyone for making a bad decision. >> >> >> >> Hope this helps. >> >> thanks, >> >> -rohan >> >> >> >> On 3/7/06, *Jonathan Rosenberg* < jdrosen@cisco.com >> >> >> > wrote: >> >> >> >> At the last IETF, there was a lot of discussion and >> argument >> around >> >> PRACK. The spark of this debate was the ICE >> specification, which >> had >> >> words in it requiring the usage of PRACK and=20 >UPDATE in >> order to >> work >> >> with early media. There was strong pushback from many >> implementors >> >> that >> >> anything requiring PRACK is unacceptable.=20 >Rohan put up a >> slide >> (IIRC) >> >> that showed the state machine in his implementation >> resulting >> from >> >> PRACK, and it was not pretty. >> >> >> >> So, I'd like to discuss exactly what IS the=20 >problem with >> PRACK? >> There >> >> are really two pieces of state machinery in=20 >play here. >> One piece >> >> is the >> >> complication that PRACK introduces into the=20 >offer/answer >> model. >> With >> >> PRACK, you can now get a final answer in the 18x, and >> then send a >> new >> >> offer in UPDATE, or even in PRACK itself.=20 >Another piece >> is the >> state >> >> machinery with the retransmissions itself -=20 >correlating >> the PRACK >> >> with a >> >> particular reliable provisional response and=20 >causing it >> to stop. >> >> >> >> In a chat with Flemming today, he suggested in >> interested remedy >> >> to our >> >> PRACK dilemma. Why not revise PRACK so that you can't >> send an >> offer or >> >> answer with it; it has no impact on the set=20 >of allowed O/A >> exchanges >> >> defined by RFC 3261. I'm not sure if that would >> consequently >> break the >> >> preconditions mechanism, but maybe there are=20 >some kind of >> offer/answer >> >> limitations that would simplify things. >> >> >> >> So, this is one idea. I'd like for people who have >> complained >> about >> >> PRACK implementations to speak up and indicate what >> exactly makes >> >> it so >> >> complicated for them. >> >> >> >> Thanks, >> >> Jonathan R. >> >> -- >> >> Jonathan D. Rosenberg, Ph.D. 600 >> Lanidex Plaza >> >> Cisco Fellow =20 >> Parsippany, NJ >> >> 07054-2711 >> >> Cisco Systems >> >> jdrosen@cisco.com >> >> < mailto:jdrosen@cisco.com> =20 > =20 >> FAX: =20 >> >> (973) 952-5050 >> >> http://www.jdrosen.net=20 > =20 >> PHONE: (973) >> 952-5000 >> >> http://www.cisco.com >> >> >> >> _______________________________________________ >> >> Sip mailing list =20 >> https://www1.ietf.org/mailman/listinfo/sip >> >> > > >> >> This list is for NEW development of the core=20 >SIP Protocol >> >> Use sip-implementors@cs.columbia.edu >> >> >> =20 >for questions on >> current sip >> >> Use sipping@ietf.org < >> mailto:sipping@ietf.org> for new >> >> developments on the application of sip >> >> >> >> >> >> _______________________________________________ >> >> 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 < >> mailto: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 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on >> current sip >> Use sipping@ietf.org for new >> developments on the application of sip >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on >> current sip >> Use sipping@ietf.org for new >> developments on the application of sip >>=20 >>=20 >>=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 > >_______________________________________________ >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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 10:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJB2F-0006mr-G8; Tue, 14 Mar 2006 10:02:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJB2D-0006mm-6C for sip@ietf.org; Tue, 14 Mar 2006 10:02:05 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJB2C-0003mj-Rd for sip@ietf.org; Tue, 14 Mar 2006 10:02:05 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 50FD34F0037; Tue, 14 Mar 2006 16:02:04 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 16:02:03 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 16:02:03 +0100 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] The Problem with PRACK Date: Tue, 14 Mar 2006 16:02:03 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHcffXsADkxez6RWuxGWsIjEN2nAABfZHg From: "Christer Holmberg \(JO/LMF\)" To: "Brett Tate" , "Juha Heinanen" X-OriginalArrivalTime: 14 Mar 2006 15:02:03.0581 (UTC) FILETIME=[40D24ED0:01C64778] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 agree with Brett. When 100rel is used it gives a possibility to ACCEPT an offer, and send an answer BEFORE 200 OK. Of course the UAS can reject the offer in the INVITE, but that has nothing to do with reliable 18x:s or PRACK. Regards, Christer=20 -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com]=20 Sent: 14. maaliskuuta 2006 16:17 To: 'Juha Heinanen' Cc: sip@ietf.org Subject: RE: [Sip] The Problem with PRACK > > As currently specified (rfc3261 section 13.2.1) for offer/answer, a=20 > > 18x with SDP sent over a reliable transport without use of 100rel is > > not considered an answer. Thus if 100rel is not used, UPDATE cannot > > carry a related offer since there is still an outstanding offer=20 > > without an official answer. >=20 > if offer in invite is not acceptable, why not reject it and tell what=20 > kind of offer would have been acceptable? My comment has nothing to do with acceptability of the SDP. =20 My comment is to indicate that reliability of transport currently has nothing to do with "reliability" related to offer/answer rules. Thus 100rel is currently still required on reliable transports for offer/answer reasons. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 10:09:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJB7o-00015i-Ew; Tue, 14 Mar 2006 10:07:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJB7m-00015d-LV for sip@ietf.org; Tue, 14 Mar 2006 10:07:50 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJB7m-00044w-3K for sip@ietf.org; Tue, 14 Mar 2006 10:07:50 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7D3CBD6E; Tue, 14 Mar 2006 16:07:49 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 16:07:48 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 16:07:48 +0100 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: Dialog usage: Forking impacts Date: Tue, 14 Mar 2006 16:07:48 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B53@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: Dialog usage: Forking impacts Thread-Index: AcZCzkcWQTDrMdxTSrKx1Rae8z/rWwBP+6gAANqjE4A= From: "Christer Holmberg \(JO/LMF\)" To: "Xiao Wang" , "Paul Kyzivat" X-OriginalArrivalTime: 14 Mar 2006 15:07:48.0744 (UTC) FILETIME=[0E8E0080:01C64779] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 >>I think that reuse early dialog may be risk. Because SUBSCRIBE may arrive >>at UA1 before 1xx or 2xx for the reason of net delay or lose, so UA1 >>doesn't find out a match dialog for SUBSCRIBE, finally the SUBSCRIBE will be=20 >>dropped, and return 400. >=20 >If UA2 sends an *confirmed* 1xx to establish the early dialog, and=20 >then sends the subscribe after receiving confirmation (via prack) then=20 >there is no risk. [Xiao]Right.=20 [CHH] I also agree. However, at the same time it is allowed to send NOTIFY before a 200 OK has been received for a SUBSCRIBE/REFER request, i.e. before the dialog (or dialog usage) has been established. Regards, Christer > > > > > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: Friday, March 03, 2006 11:26 PM > >>To: Christer Holmberg (JO/LMF) > >>Cc: IETF SIP List > >>Subject: [Sip] Re: Dialog usage: Forking impacts > >> > >> > >> > >>Christer Holmberg (JO/LMF) wrote: > >> > >>>Hi, > >>> > >>>Another scenario related to the dialog usage issue: > >>> > >>>1. UA_1 sends an INVITE, which gets forked to UA_2 and UA_3. > >>> > >>>2. UA_2 establish an early dialog with UA_1 and sends a SUBSCRIBE > >>>(or any other request establishing a new dialog usage) to UA_1,=20 > >>>establishing a dialog usage (subscribe dialog usage in case of > > > > SUBSCRIBE). > > > >>>3. UA_3 acceptes the session for the INVITE and sends 200 OK > > > > (INVITE) > > > >>>4. The forking proxy sends a CANCEL to UA_2, and forwards the 200 > >>>OK (INVITE) to UA_1. > >>> > >>>5. UA_1, when receiving the 200 OK, would normally terminate the > >>>early dialog between itself and UA_2. BUT, in this case it can't do > >>>it, because it still has an active subscription dialog usage=20 > >>>association with UA_2, and the CANCEL sent by the proxy didn't=20 > >>>terminate that dialog > >>>usage in UA_2 either. > >> > >>This does point up some issues with language in the RFCs. I doubt=20 > >>there really is any such thing as an "early dialog". In reality=20 > >>there is only one kind of dialog, but there is an "early invite dialog usage". > >> > >> > >>>Now, the dialog usages still share the same dialog, but from the=20 > >>>UA_1 perspective each dialog usage has DIFFERENT route sets and=20 > >>>remote > > > > targets... > > > >>Don't think I agree. Following step 3, or maybe sooner, UA1 knows=20 > >>there are two dialogs, because it has received responses with=20 > >>different to-tags. The early invite dialog usage with UA2 and the=20 > >>subscribe from > >>UA2 share one dialog, and the invite dialog usage with UA3 uses the=20 > >>other dialog. > >> > >>There isn't anything new here due to sharing. UA2 and UA3 could have > >>both established early invite dialog usages. UA1 has to deal with=20 > >>two dialogs in that case as well. > >> > >>The key thing in all this is that the lifetime of dialogs is not=20 > >>explicitly managed. Rather it is reference counted based on the=20 > >>usages that share it. > >> > >> > >>>Saying that dialog re-usage is only allowed for FULLY ESTABLISHED=20 > >>>dialogs would of course solve this, but currentely I think it's=20 > >>>legal from a pure SIP perspective. Or? > >> > >>This is one of the reasons why I think it is a bad idea to start=20 > >>putting restrictions on the use of shared dialogs. As things stand,=20 > >>the whole ediface does tie together using just a few basic=20 > >>principles. If you support those principles, then all the different=20 > >>possible combinations of usages will work. If you impose=20 > >>restrictions on the kinds of usages that are allowed, you encourage=20 > >>implementations that implement all sorts of special case logic.=20 > >>Figuring out what special case logic is sufficient is harder than implementing the general case. > >> > >> Paul > >> > >> > >>>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 > > > > > > > > > > _______________________________________________ > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 10:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJBEe-0004gQ-C1; Tue, 14 Mar 2006 10:14:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJBEc-0004gL-G9 for sip@ietf.org; Tue, 14 Mar 2006 10:14:54 -0500 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 1FJBEb-0004Jl-7h for sip@ietf.org; Tue, 14 Mar 2006 10:14:54 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 14 Mar 2006 07:14:53 -0800 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 k2EFEqw1020941 for ; Tue, 14 Mar 2006 07:14:52 -0800 (PST) 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.211); Tue, 14 Mar 2006 07:14:52 -0800 Received: from [10.21.98.12] ([10.21.98.12]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 07:14:51 -0800 Message-ID: <4416DDEB.3030009@cisco.com> Date: Tue, 14 Mar 2006 10:14:51 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt References: <4416D284.3000203@lucent.com> In-Reply-To: <4416D284.3000203@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2006 15:14:51.0850 (UTC) FILETIME=[0ABEDAA0:01C6477A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Cullen Jennings , "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 > Cullen Jennings wrote: > >> I know of several proxies today that will support multiple domains. >> However, >> all the ones that I have seen that do TLS require a separate port for >> each >> domain. That is because the TLS extensions to specify the domain in the >> handshake are not that widely used yet. In the long run this doesn't seem good enough. I would like to have the option of having my home cable provider host my private domain for me. But that provider can't reasonably have a separate port for every domain it hosts. 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 Tue Mar 14 10:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJBl7-00047B-A9; Tue, 14 Mar 2006 10:48:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJBl6-000476-Bn for sip@ietf.org; Tue, 14 Mar 2006 10:48:28 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJBl4-00051T-AZ for sip@ietf.org; Tue, 14 Mar 2006 10:48:28 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2EFkQCj015444; Tue, 14 Mar 2006 17:46:26 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 17:48:20 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 17:48:18 +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] The Problem with PRACK Date: Tue, 14 Mar 2006 17:48:18 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0212EC2C@esebe103.NOE.Nokia.com> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B51@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZDlqOrQGOJVrmUTly6shAze7mvMADxu20gAAZ/myAAAVDR0A== From: To: , , X-OriginalArrivalTime: 14 Mar 2006 15:48:18.0875 (UTC) FILETIME=[B70690B0:01C6477E] X-Spam-Score: 0.2 (/) X-Scan-Signature: ceb20e3ccfd90d068e2ad6c8a4781b53 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, >3GPP has now also defined procedures where the usage of the=20 >precondition mechanism is not mandated. True, but I do not still agree that the problem would be non-existent. Excuse me citing 3GPP specs here, but I just want to highlight the foreseeable backwards compatibility problems towards existing mobile SIP implementations, that could result if offer within PRACK would be obsoleted. Originally the usage of preconditions was mandatory for 3GPP IMS. 3GPP specs are still promoting the usage of preconditions as the=20 preferred option like this (UE effectively meaning UA in IETF terms): "The preconditions mechanism should be supported by the originating UE. The UE may initiate a session without the precondition mechanism if the originating UE does not require local resource reservation. The originating UE can decide if local resource reservation is required based on e.g. application requirements, current access network capabilities, local configuration, etc. In order to allow the peer entity to reserve its required resources, an originating UE supporting the precondition mechanism should make use of the precondition mechanism, even if it does not require local resource reservation." And sending offer within PRACK is specified in 3GPP like this: "Upon successful reservation of local resources the UE shall confirm the successful resource reservation within the next SIP request. In case of the precondition mechanism being used on both sides, this confirmation will be sent in either a PRACK request or an UPDATE request." Regards, Erkki >-----Original Message----- >From: ext Christer Holmberg (JO/LMF)=20 >[mailto:christer.holmberg@ericsson.com]=20 >Sent: 14.March.2006 16:58 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki);=20 >pkyzivat@cisco.com; princeap@gmail.com >Cc: sip@ietf.org >Subject: RE: [Sip] The Problem with PRACK > > >Hi, > >3GPP has now also defined procedures where the usage of the=20 >precondition >mechanism is not mandated. > >Regards, > >Christer > >=20 > >-----Original Message----- >From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 >Sent: 14. maaliskuuta 2006 14:09 >To: pkyzivat@cisco.com; princeap@gmail.com >Cc: sip@ietf.org >Subject: RE: [Sip] The Problem with PRACK > >=20 > >Hi, > >>> PRACK dilemma. Why not revise PRACK so that you can't send an offer >or=20 >>> answer with it; it has no impact on the set of allowed O/A=20 >exchanges=20 >>> defined by RFC 3261. > >> In any case, any change like this must be accompanied by a some >strategy=20 >> for backward compatibility. This seems not so easy. As much as it is >fun=20 >> to imagine how it might have been done better the first time=20 >around, I > >> suspect that at this point the cure is worse than the disease. > >I would just like to point out that the session setup=20 >specified for 3GPP >IMS networks uses preconditions and implicitely assume sending an offer >within PRACK. This is done for efficiency reasons like Paul indicated: > >>Allowing an offer in PRACK is less motivated. Essentially the same=20 >>thing can be done using UPDATE. I can speculate on some reasons for=20 >>allowing PRACK to be used for this: >>- efficiency - the prack is required anyway > >The 3GPP call setup with preconditions consists of 4 SIP transactions: >INVITE, two PRACKs for reliable responses and one UPDATE, covering two >to three offer-answer exchanges. All this (performed over long-range >radio access) will take considerable amount of time, more than 10 >seconds in the worst case. Adding yet another UPDATE transaction to >those would make the setup time even longer. > >This far 3GPP has adopted a strategy to be compliant to IETF specs. >However obsoleting PRACK to contain an SDP offer would have a backward >compatibility problem towards all 3GPP compliant implementations, >whether they would be applied within IMS networks or Internet. > >Anyway the issue here is that for any transport requiring resource >reservation (and preconditions) and providing long RTT, this kind of >change would push session setup times to their limits, no more >acceptable to average users. > >Regards, > >Erkki > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 09.March.2006 18:29 >>To: Prince A P >>Cc: sip@ietf.org >>Subject: Re: [Sip] The Problem with PRACK >> >> >> >>Prince A P wrote: >>> Hi, >>> =20 >>> If the 3262 is only for Reliability of Provisional >>responses, Why should >>> it mandate Offer-Answer completion? >>> Was there any rationale behind clubbing Reliability with >>Offer-Answer? >> >>I wasn't there when that was done, so I can't speak to the actual=20 >>motives of those who were. >> >>But note that offer/answer has no mechanism of its own - it must be=20 >>associated with some messages in the signaling system. >> >>Reliable provisionals, without sdp in the PRACK, are sufficient for=20 >>early completion of the offer/answer exchange when the offer=20 >is in the=20 >>invite. But that isn't sufficient to achieve early completion of=20 >>offer/answer when there is no offer in the invite. In that case the=20 >>offer is in the reliable provisional, and the obvious place for the=20 >>answer is in the PRACK. That seems to be reasonable justification for=20 >>involving PRACK in offer/answer. >> >>Allowing an offer in PRACK is less motivated. Essentially the same=20 >>thing can be done using UPDATE. I can speculate on some reasons for=20 >>allowing PRACK to be used for this: >>- done before UPDATE was invented >>- efficiency - the prack is required anyway >>- prack already needs to carry an answer, why not an offer >> >> Paul >> >>> =20 >>> rgds, >>> Prince >>>=20 >>>=20 >>> =20 >>>=20 >>> To: "Samir Srivastava" < samirsr@nortel.com >>> >, "Paul Kyzivat"=20 >>>> >, "Francois Audet" < >>> audet@nortel.com > >>> From: "Samir Srivastava" < samirsr@nortel.com >>> > >>> Date: 03/09/2006 01:18PM >>> cc: IETF SIP List > >>> Subject: RE: [Sip] The Problem with PRACK >>>=20 >>> We can do it, by adding more logic / header. UAS >>knows about all the >>> hops by complete via header set inspection. When >>sending 1xx, it >>> need to >>> indicate in this new header to be defined. Is it worth >>> defining this ? >>>=20 >>>=20 >>> Thx >>> Samir >>>=20 >>> -----Original Message----- >>> From: Srivastava, Samir [SC100:8826:EXCH] >>> Sent: Wednesday, March 08, 2006 11:19 PM >>> To: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH] >>> Cc: IETF SIP List >>> Subject: RE: [Sip] The Problem with PRACK >>>=20 >>> We can do for SIPS only. >>>=20 >>> Thx >>> Samir >>>=20 >>> -----Original Message----- >>> From: Paul Kyzivat [ mailto:pkyzivat@cisco.com] >>> Sent: Wednesday, March 08, 2006 7:29 PM >>> To: Audet, Francois [SC100:3055:EXCH] >>> Cc: IETF SIP List >>> Subject: Re: [Sip] The Problem with PRACK >>>=20 >>>=20 >>>=20 >>> Francois Audet wrote: >>> > I'm ok with the suggestion to deprecate using PRACK for >>> Offer/Answer. >>> > >>> > While we are at it, why not go for deprecating >>the use PRACK >>> > altogether when TCP transport is used? >>>=20 >>> Explain to me again how you would know that reliable >>transport >>> is used >>> end to end? >>>=20 >>> Paul >>>=20 >>> > On Mar 8, 2006, at 15:51 , Rohan Mahy wrote: >>> > >>> >> Hi, >>> >> >>> >> A things about PRACK come immediately to mind >>that are a pain to >>> >> implement: >>> >> >>> >> 1) The UAS has to queue provisionals until it receives a >>> PRACK for >>> >> the first provisional. This is due to RSeq >>starting at an >>> arbitrary >>> >> value instead of just starting at 1. This is >>probably the >>> simplest >>> >> to fix, by just requiring the UAC to always start with a >>> RSeq of 1. >>> >> >>> >> 2) Multiple unacknowledged provisionals can be >>in flight at >>> the same >>> >> time. We could potentially eliminate this=20 >requirement by >>> >> acknowledging the current status instead of the whole >>> history. In >>> >> other words, when the UAS sends a new reliable >>provisional, it >>> >> decides which (if any) of the previously sent >>provisionals >>> are still >>> >> relevant and sends all of them (as sipfrags or >>something) as >>> a single >>>=20 >>> >> reliable request. >>> >> >>> >> 3) If you "answer" and want to deliver a 200 OK, >>you have to >>> queue it >>>=20 >>> >> and wait if you are waiting for a PRACK to an >>offer or answer. >>> >> Keeping track of when you can send the 200 would >>be easier >>> if we did >>> >> something like I recommend in #2. >>> >> >>> >> 4) Even for an acknowledged provisional, you >>still have to >>> retransmit >>>=20 >>> >> approximately every minute (I forget exactly) to >>prevent old >>> proxies >>> >> from deleting state for your transaction. This=20 >is one of >>> those minor >>>=20 >>> >> annoyances that is *almost* operationally=20 >irrelevant, and >>> unlikely to >>>=20 >>> >> not get coded. My proposal for simplification is to >>> retransmit the >>> >> latest reliable provisional in exactly the same >>way that the >>> UAS >>> >> retransmits unreliable provisionals. Who cares >>if there is >>> an extra >>> >> message or two for a call with 1 minute + >>post-answer delay? >>> >> >>> >> 5) I would deprecate the PRACK/200 (PRACK) offer/answer >>> exchange. I >>> >> talked Jonathan into this, and I've been sorry=20 >I did ever >>> since. My >>> >> apologies to everyone for making a bad decision. >>> >> >>> >> Hope this helps. >>> >> thanks, >>> >> -rohan >>> >> >>> >> On 3/7/06, *Jonathan Rosenberg* < jdrosen@cisco.com >>> >>> >> > wrote: >>> >> >>> >> At the last IETF, there was a lot of discussion and >>> argument >>> around >>> >> PRACK. The spark of this debate was the ICE >>> specification, which >>> had >>> >> words in it requiring the usage of PRACK and=20 >>UPDATE in >>> order to >>> work >>> >> with early media. There was strong pushback=20 >from many >>> implementors >>> >> that >>> >> anything requiring PRACK is unacceptable.=20 >>Rohan put up a >>> slide >>> (IIRC) >>> >> that showed the state machine in his implementation >>> resulting >>> from >>> >> PRACK, and it was not pretty. >>> >> >>> >> So, I'd like to discuss exactly what IS the=20 >>problem with >>> PRACK? >>> There >>> >> are really two pieces of state machinery in=20 >>play here. >>> One piece >>> >> is the >>> >> complication that PRACK introduces into the=20 >>offer/answer >>> model. >>> With >>> >> PRACK, you can now get a final answer in=20 >the 18x, and >>> then send a >>> new >>> >> offer in UPDATE, or even in PRACK itself.=20 >>Another piece >>> is the >>> state >>> >> machinery with the retransmissions itself -=20 >>correlating >>> the PRACK >>> >> with a >>> >> particular reliable provisional response and=20 >>causing it >>> to stop. >>> >> >>> >> In a chat with Flemming today, he suggested in >>> interested remedy >>> >> to our >>> >> PRACK dilemma. Why not revise PRACK so that=20 >you can't >>> send an >>> offer or >>> >> answer with it; it has no impact on the set=20 >>of allowed O/A >>> exchanges >>> >> defined by RFC 3261. I'm not sure if that would >>> consequently >>> break the >>> >> preconditions mechanism, but maybe there are=20 >>some kind of >>> offer/answer >>> >> limitations that would simplify things. >>> >> >>> >> So, this is one idea. I'd like for people who have >>> complained >>> about >>> >> PRACK implementations to speak up and indicate what >>> exactly makes >>> >> it so >>> >> complicated for them. >>> >> >>> >> Thanks, >>> >> Jonathan R. >>> >> -- >>> >> Jonathan D. Rosenberg, Ph.D. 600 >>> Lanidex Plaza >>> >> Cisco Fellow =20 >>> Parsippany, NJ >>> >> 07054-2711 >>> >> Cisco Systems >>> >> jdrosen@cisco.com >>> >> < mailto:jdrosen@cisco.com> =20 >> =20 >>> FAX: =20 >>> >> (973) 952-5050 >>> >> http://www.jdrosen.net=20 >> =20 >>> PHONE: (973) >>> 952-5000 >>> >> http://www.cisco.com >>> >> >>> >> _______________________________________________ >>> >> Sip mailing list =20 >>> https://www1.ietf.org/mailman/listinfo/sip >>> >> >> > >>> >> This list is for NEW development of the core=20 >>SIP Protocol >>> >> Use sip-implementors@cs.columbia.edu >>> >>> >> =20 >>for questions on >>> current sip >>> >> Use sipping@ietf.org < >>> mailto:sipping@ietf.org> for new >>> >> developments on the application of sip >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 < >>> mailto: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=20 >Protocol Use >>> sip-implementors@cs.columbia.edu >>> for questions on >>> current sip Use >>> sipping@ietf.org for new >>developments >>> on the application of sip >>>=20 >>>=20 >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu >>> for questions on >>> current sip >>> Use sipping@ietf.org for new >>> developments on the application of sip >>>=20 >>>=20 >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu >>> for questions on >>> current sip >>> Use sipping@ietf.org for new >>> developments on the application of sip >>>=20 >>>=20 >>>=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 >> >>_______________________________________________ >>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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 12:20:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJDAp-0006ld-H4; Tue, 14 Mar 2006 12:19:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJDAn-0006kn-HB for sip@ietf.org; Tue, 14 Mar 2006 12:19:05 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJDAn-00081I-0i for sip@ietf.org; Tue, 14 Mar 2006 12:19:05 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2EHHnSL010400; Tue, 14 Mar 2006 19:17:51 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 19:18:58 +0200 Received: from localhost.localdomain ([172.21.50.42]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 14 Mar 2006 19:18:57 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k2EHIuqb001705; Tue, 14 Mar 2006 19:18:57 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id k2EHIuuR001704; Tue, 14 Mar 2006 19:18:56 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Cullen Jennings Subject: Re: [Sip] The Problem with PRACK X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: (Cullen Jennings's message of "Sun, 12 Mar 2006 12:27:21 -0800") References: Date: Tue, 14 Mar 2006 19:18:55 +0200 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 14 Mar 2006 17:18:57.0848 (UTC) FILETIME=[60E7FB80:01C6478B] 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: , Errors-To: sip-bounces@ietf.org Cullen Jennings writes: >One of the difficult parts of PRACK has to do with fact that >there are times when a UA can not sent a new set of SDP and has >to wait until some current round completed then merge in all the >SDP changes it wanted. I have not seen a single implementation >that correctly implemented this. I imagine there are some correct >implementation but the fact that there are so many wrong once >suggests this is very hard to get right. It must hard to make a distributed UA. But doesn't 3261 and 3264 say that the current round must be completed before sending new offer? I don't see any difference between ACK and PRACK in this sense, both must be sent at once. I must be missing what makes PRACK so different and hard. Only possible addditional difficulty I see here is deciding whether the SDP in PRACK is offer or answer. If UA has sent offer in 100rel, it is answer, otherwise it is offer. Two bits in your negotiation engine, or four states (init/sent-offer/recv-offer/ complete) in a SDL-like service. The really interesting parts come with UPDATE, where the recipient of INVITE can send an answer in 100rel and after it has received PRACK it can decide that it has done enough this answering thing and proceed to send an offer in UPDATE. It must be prepared to get 491 and retry UPDATE, but that is again standard part of implementing UPDATE. >The things that make PRACK hard may have to do with rigid limits >on what can be correlated between an offer and answer in SDP. In >finding a solution to PRACK, we might need to consider if we need >slightly more powerful correlation facilities in SDP such that we >can relax some of the current SIP level rules that make PRACK so >hard. Such as? --Pekka >On 3/7/06 11:32 PM, "Jonathan Rosenberg" wrote: >> At the last IETF, there was a lot of discussion and argument around >> PRACK. The spark of this debate was the ICE specification, which had >> words in it requiring the usage of PRACK and UPDATE in order to work >> with early media. There was strong pushback from many implementors that >> anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) >> that showed the state machine in his implementation resulting from >> PRACK, and it was not pretty. >> So, I'd like to discuss exactly what IS the problem with PRACK? There >> are really two pieces of state machinery in play here. One piece is the >> complication that PRACK introduces into the offer/answer model. With >> PRACK, you can now get a final answer in the 18x, and then send a new >> offer in UPDATE, or even in PRACK itself. Another piece is the state >> machinery with the retransmissions itself - correlating the PRACK with a >> particular reliable provisional response and causing it to stop. >> In a chat with Flemming today, he suggested in interested remedy to our >> PRACK dilemma. Why not revise PRACK so that you can't send an offer or >> answer with it; it has no impact on the set of allowed O/A exchanges >> defined by RFC 3261. I'm not sure if that would consequently break the >> preconditions mechanism, but maybe there are some kind of offer/answer >> limitations that would simplify things. >> So, this is one idea. I'd like for people who have complained about >> PRACK implementations to speak up and indicate what exactly makes it so >> complicated for them. >> Thanks, >> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 13:19:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJE52-00005i-Fn; Tue, 14 Mar 2006 13:17:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJE3c-0007zX-06 for sip@ietf.org; Tue, 14 Mar 2006 13:15:44 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJDv0-0000oa-IN for sip@ietf.org; Tue, 14 Mar 2006 13:06:51 -0500 Received: (qmail 9595 invoked by uid 0); 14 Mar 2006 18:06:46 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 14 Mar 2006 18:06:46 -0000 Message-ID: <006f01c64792$0abb9260$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" , References: Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt Date: Tue, 14 Mar 2006 19:06:39 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Cullen, > > If a proxy hosts two domain one.example.com and two.example.com on the > same > IP and port, this does not seem to work. The wrong TLS connection would be > used. The problem is the cache is populated with the IP/port as the index > instead of using the cert name as the index. > At first I did not understand your point, until I saw your other posting on the -04 version: [copy] | Second, I don't think it works. If a server runs two virtual domain a.com | and b.com both on 1.2.3.4:5060 and use the TLS extended hello to separate | them, then if it connects to C as A.com, and later C wants to send a sips | message to B.com, it will deliver it over the connection to A.com which is | totally broken from a security point of view. So what you're saying is that a TLS connection should not be used to multiplex traffic for different virtual domains, even though it is known to end up at the exact same host and port? If A.com really feels that way, I suppose the solution would be for it to not request an alias when it connects to C. But to be honest, since it can be verified that the connection to A.com arrives at the same host and port as B.com, I don't see why this would be "totally broken". Could you expand on that? 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 Mar 14 13:29:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJEFg-00061u-6D; Tue, 14 Mar 2006 13:28:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJEFf-00061o-0k for sip@ietf.org; Tue, 14 Mar 2006 13:28:11 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJEFd-0001RL-NL for sip@ietf.org; Tue, 14 Mar 2006 13:28:10 -0500 X-IronPort-AV: i="4.02,191,1139202000"; d="scan'208"; a="30018512:sNHT46300356" 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] content indirection design question Date: Tue, 14 Mar 2006 13:28:07 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647026A33BA@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] content indirection design question Thread-Index: AcY5sHEJGQq2HN/xROWpRuWtJ0PafAN5GE9A From: "Burger, Eric" To: "Nasir Khan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Dean is precisely correct. While the mechanism does not look compatible with other SIP stuff, it is the mechanism for MIME, which SIP is transporting. There is a ton of MIME infrastructure that we chose not to break here. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Friday, February 24, 2006 5:26 PM To: Nasir Khan Cc: sip@ietf.org Subject: Re: [Sip] content indirection design question On Feb 24, 2006, at 4:09 PM, Nasir Khan wrote: > I have this question for the designers of http://www.ietf.org/=20 > internet-drafts/draft-ietf-sip-content-indirect-mech-05.txtThe way =20 > the meta data about the indirect content is split between message =20 > and body is counter-intuitive. Eg. -----------------------------=20 > Actual------------------------- Content-=20 > Type: message/external-body; access-type=3D"URL"; =20 > expiration=3D"Mon, 24 June 2002 09:00:00 GMT"; =20 > URL=3Dhttp://www.example.com/the-indirect-content Content-=20 > Length : 234 Content-Type: image/=20 > jpeg Content-Disposition: =20 > render--------------------------------- The Content-Type header =20 > indicates that this is an indirect content and also contains the =20 > pointer to the actual content, it contains a lot of other =20 > information about the content and then there is a Content-Length =20 > that is not the length of the actual content but the length of the =20 > content attributes that appear as Content headers in the body of =20 > this message, which contains some further information about the =20 > content. This type of semantic overloading and distribution has not =20 > been seen in most of the SIP design that I am aware of so far, what =20 > were the reasons for this design decision? You could have defined =20 > a simple protocol (which you have done indirectly) which is =20 > transported in the message body much like SDP and defines the =20 > content as indirect content, as an example .. Eg. =20 > ------------------------=20 > Suggested-------------------------------------------Content-Type: =20 > application/indirect-contentContent-Length: 563Indirect-=20 > Content-Param: URL;expiration=3D"Mon, 24 June 2002 09:00:00 =20 > GMT"Indirect-Content: http://www.example.com/the-indirect-=20 > contentIndirect-Content-Type: image/jpegIndirect-Content-Length : =20 > 234532Indirect-Content-Description : Happy fish image......etc etc. > ---------------------------------------------------------------------- > ------------ > > > > OR alternatively > > You could have extended SIP by adding these headers (Indirect-XXX) =20 > headers in this draft to describe the indirect content and left the =20 > body empty. > > > > Any of these approaches simplify the UA implementation, =20 > particularly in approach-1 that I describe above, I could have used =20 > a factory generated pluggable content protocol handler which is =20 > delegated to deal with the content it specializes in, selectable by =20 > Content-Type header alone which just reads the body of the message =20 > after , where it finds Interesting email format, seems to be devoid of newlines. The history is like this: MIME had already defined message/external-=20 body (RFC 2017) and its semantics. This approach was used in ietf-=20 announce email for years, and I believe was still being used at the =20 time SIP content indirection was introduced. In the usual IETF =20 tradition, we re-used it rather than inventing yet another MIME type. =20 Generality over simplicity, and all that. Besides, this was what the MIME people told us to do. -- 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 Mar 14 14:57:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJFcR-0003wC-Pc; Tue, 14 Mar 2006 14:55:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJFcQ-0003vO-Kc for sip@ietf.org; Tue, 14 Mar 2006 14:55:46 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJFcP-0003Ov-77 for sip@ietf.org; Tue, 14 Mar 2006 14:55:46 -0500 Received: (qmail 17498 invoked by uid 0); 14 Mar 2006 19:55:40 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 14 Mar 2006 19:55:40 -0000 Message-ID: <010701c647a1$414a6860$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" , References: Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-02.txt Date: Tue, 14 Mar 2006 20:55:33 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 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 >> Section 3.5: the statement "[...] most operating systems do not allow the >> time to be set on a per connection basis." is not true. Although I must >> admist I have no personal programming experience on this, Linux seems to >> offer "3 non-standard TCP socket options for tweaking the keepalive >> behavior >> of individual sockets: TCP_KEEPIDLE, TCP_KEEPCNT, and TCP_KEEPINTVL. The >> values set on a socket with these options should override the system-wide >> default.[http://www.ussg.iu.edu/hypermail/linux/kernel/0508.2/0745.html]. >> Windows offers WSAIoctl with SIO_KEEPALIVE_VALS, which also provides >> per-connection setting of keep-alive (enable, time and interval) > > Wow - interesting. Long, Long ago when I wrote this, I went and looked in > Windows 2k, Linux, and Solaris. I must has missed this. Thanks for finding > this - I must have done a lousy job of looking. Have you done any testing > to > see if we can use this and avoid the whole STUN argument we have been > having. I have just done some basic testing on the Windows (XP) implementation of TCP keep-alive. I used the following code (s = a tcp socket): #include // for tcp_keepalive int val = TRUE; ::setsockopt( s, SOL_SOCKET, SO_DONTLINGER, (const char*) &val, sizeof(val) ); ::setsockopt( s, SOL_SOCKET, SO_KEEPALIVE, (const char*) &val, sizeof(val) ); ::setsockopt( s, IPPROTO_TCP, TCP_NODELAY, (const char*) &val, sizeof(val) ); tcp_keepalive settings; settings.onoff = 1; settings.keepaliveinterval = 1000; // interval of a probe when failed, in ms settings.keepalivetime = 60000; // every X ms, default is 2 hours DWORD nBytes=0; int r = ::WSAIoctl( s, SIO_KEEPALIVE_VALS, &settings, sizeof(settings), NULL, 0, &nBytes, NULL, NULL ); // succeeds, r==0 This causes the client to send a TCP keep-alive segment with SEG.SEQ = SND.NXT-1 as per RFC1122, containing 1 byte of garbage data (byte 00) and DF flag set. It sends the first probe 60 seconds after the connection has been idle (I only performed a TCP REGISTER over it), and repeats this every interval as specified. Different values give different intervals, and other connections are not affected. The server (a win2k machine I think) responds with a TCP ACK segment My conclusion: This seems usable... 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 Mar 14 16:24:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJGyB-0000vO-8g; Tue, 14 Mar 2006 16:22:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJGy9-0000vJ-B0 for sip@ietf.org; Tue, 14 Mar 2006 16:22:17 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJGy8-00060l-0f for sip@ietf.org; Tue, 14 Mar 2006 16:22:17 -0500 Received: from [206.176.144.212] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2ELMVT7014551 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 14 Mar 2006 15:22:33 -0600 In-Reply-To: <1142322506.6820.1.camel@eeek.ingate.se> References: <1142322506.6820.1.camel@eeek.ingate.se> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 Date: Tue, 14 Mar 2006 15:22:05 -0600 To: Hans Persson X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Cullen Jennings , "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 Mar 14, 2006, at 1:48 AM, Hans Persson wrote: > m=E5n 2006-03-13 klockan 22:59 -0800 skrev Cullen Jennings: > >> I doubt that Identity breaks B2BUA in the cases that I have heard =20 >> of. I >> roughly break the cases into two classes - ones where the B2BUA =20 >> wants to >> assert a new identity because it is hiding the old one; And cases =20 >> where it >> is in the same domain as the original party. In either case the =20 >> B2BUA can >> have the credentials to be able to re-sign the identity in the =20 >> message. I'm >> won't be surprised if someone comes up with a case where it is a =20 >> problem but >> so far, everyone I have heard of has not been a problem. > > I'd rather expect problem in the opposite direction. If the B2BUA =20 > wants > to terminate incoming calls, then the receiving client won't be =20 > able to > verify the identity of the caller since the B2BUA will have =20 > modified the > body (at least) of the incoming request since the creation of the > Identity header. > yes, that's exactly the case I was worrying over. At the best, the =20 SBC can tell the terminating UA what the identity it received was and =20= claim to have checked that identity on behalf of the terminating UA. =20 This is in effect a new assertion of identity, based on a transitive =20 trust agreement. -- 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 Mar 14 16:35:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJH8l-00069K-Nw; Tue, 14 Mar 2006 16:33:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJH8k-00069C-4T for sip@ietf.org; Tue, 14 Mar 2006 16:33:14 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJH8i-0006Jx-CQ for sip@ietf.org; Tue, 14 Mar 2006 16:33:14 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 89A904F0001; Tue, 14 Mar 2006 22:33:11 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 22:33:10 +0100 Received: from [136.225.183.81] ([136.225.183.81]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 22:33:07 +0100 From: "Christer Holmberg" To: Erkki.Koivusalo@nokia.com, pkyzivat@cisco.com, princeap@gmail.com Subject: RE: [Sip] The Problem with PRACK Date: Tue, 14 Mar 2006 23:28:15 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 14 Mar 2006 21:33:10.0604 (UTC) FILETIME=[E441D8C0:01C647AE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, As has been said before, I don't think the precondition mechanism mandates = the usage of PRACK for offer/answer. 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 Mar 14 16:35:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJH9E-0006RE-Hl; Tue, 14 Mar 2006 16:33:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJH9D-0006Pm-5s for sip@ietf.org; Tue, 14 Mar 2006 16:33:43 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJH9B-0006KU-QX for sip@ietf.org; Tue, 14 Mar 2006 16:33:43 -0500 Received: from [206.176.144.212] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2ELY0sl014582 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 14 Mar 2006 15:34:02 -0600 In-Reply-To: <17430.47090.634650.930408@rautu.tutpro.com> References: <441057B9.8010602@cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F0212E9C4@esebe103.NOE.Nokia.com> <17430.47090.634650.930408@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39855A1F-58FB-4527-8D53-D0F57AB942CC@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Tue, 14 Mar 2006 15:33:34 -0600 To: Juha Heinanen X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.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 On Mar 14, 2006, at 6:32 AM, Juha Heinanen wrote: > Erkki.Koivusalo@nokia.com writes: > >> The 3GPP call setup with preconditions consists of 4 SIP >> transactions: >> INVITE, two PRACKs for reliable responses and one UPDATE, covering >> two to three offer-answer exchanges. > > why do you use prack rather than tcp or just udp with > retransmissions in > case 200 OK gets lost? > Preconditions. They need acknowledgement that the request was received and acted on by meeting the preconditions at both ends BEFORE alerting the terminating user. At the terminating side, this requires seeing an INVITE and "some other message" before sending back a 180 or 200 OK. While I find the requirement questionable, this was the best mechanism we could come up with back in 1999. Notes at: http://www.softarmor.com/sipwg/meets/interim-nov-1999/ Lots of design approaches were considered. We considered having an dialog for QoS preconditions, inside which we'd run another dialog for media. We considered reINVITE to move from "precondition establishment" to "media establishment". We considered lots of alternatives. We picked the PRACK model. We were probably wrong, but that's for another day. Then we found out there was an IPR issue: https://datatracker.ietf.org/public/ipr_search.cgi? option=rfc_search&rfc_search=3312 and could no longer get anybody to think much about preconditions. -- 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 Mar 14 17:40:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJIAD-0003oq-G3; Tue, 14 Mar 2006 17:38:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJIAB-0003ol-Ja for sip@ietf.org; Tue, 14 Mar 2006 17:38:47 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJIAA-0008EC-2g for sip@ietf.org; Tue, 14 Mar 2006 17:38:47 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 3C9E6140416; Wed, 15 Mar 2006 00:38:44 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 93E17140414; Wed, 15 Mar 2006 00:38:23 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 68248F027F; Wed, 15 Mar 2006 00:38:49 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17431.17913.375710.846968@rautu.tutpro.com> Date: Wed, 15 Mar 2006 00:38:49 +0200 From: Juha Heinanen To: "Brett Tate" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <000c01c64771$eed52360$2c28a8c0@brett1> References: <17430.52284.197018.217222@rautu.tutpro.com> <000c01c64771$eed52360$2c28a8c0@brett1> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Brett Tate writes: > My comment is to indicate that reliability of transport currently has > nothing to do with "reliability" related to offer/answer rules. Thus 100rel > is currently still required on reliable transports for offer/answer > reasons. final response to INVITE is always reliable without PRACK, because it is ACKed. i was just questioning, why do you need to reliable provisional responses at all, i.e., why all this complexity introduced by PRACK and UPDATE? -- ju > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 14 17:44:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJIDb-0005dH-FU; Tue, 14 Mar 2006 17:42:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJIDa-0005dC-G5 for sip@ietf.org; Tue, 14 Mar 2006 17:42:18 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJIDZ-0008Iq-5T for sip@ietf.org; Tue, 14 Mar 2006 17:42:18 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 84DFB140416; Wed, 15 Mar 2006 00:42:16 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id A968B140414; Wed, 15 Mar 2006 00:42:05 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 240BFF027E; Wed, 15 Mar 2006 00:42:33 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17431.18137.100810.717629@rautu.tutpro.com> Date: Wed, 15 Mar 2006 00:42:33 +0200 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B51@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1B51@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.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 Christer Holmberg (JO/LMF) writes: > 3GPP has now also defined procedures where the usage of the precondition > mechanism is not mandated. sounds like a much better idea than keep on complicating the protocol beyond comprehension. -- 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 Mar 14 17:59:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJISY-0004oD-TZ; Tue, 14 Mar 2006 17:57:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJISX-0004nt-0B for sip@ietf.org; Tue, 14 Mar 2006 17:57:45 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJISV-0000IF-LU for sip@ietf.org; Tue, 14 Mar 2006 17:57:44 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 1124E140415; Wed, 15 Mar 2006 00:57:43 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id EF0B8140411; Wed, 15 Mar 2006 00:57:23 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 4EC97F027E; Wed, 15 Mar 2006 00:55:28 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17431.18912.266470.211444@rautu.tutpro.com> Date: Wed, 15 Mar 2006 00:55:28 +0200 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: sip@ietf.org, Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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) writes: > When 100rel is used it gives a possibility to ACCEPT an offer, and send > an answer BEFORE 200 OK. why is it important for the UAS to accept SDP offer before accepting or rejecting the invite and why it is important for the UAC to be sure that UAS has accepted the offer before accepting or rejecting the invite? -- 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 Mar 14 18:04:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJIXm-00075x-PW; Tue, 14 Mar 2006 18:03:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJIXm-00075s-4p for sip@ietf.org; Tue, 14 Mar 2006 18:03:10 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJIXk-0000XS-Ps for sip@ietf.org; Tue, 14 Mar 2006 18:03:10 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 3B2F5140414; Wed, 15 Mar 2006 01:03:08 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 77BCD140411; Wed, 15 Mar 2006 01:02:57 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id CD6ECF027E; Wed, 15 Mar 2006 01:03:17 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17431.19381.704016.457484@rautu.tutpro.com> Date: Wed, 15 Mar 2006 01:03:17 +0200 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt In-Reply-To: <4416DDEB.3030009@cisco.com> References: <4416D284.3000203@lucent.com> <4416DDEB.3030009@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Cullen Jennings , "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 Paul Kyzivat writes: > In the long run this doesn't seem good enough. > I would like to have the option of having my home cable provider host my > private domain for me. But that provider can't reasonably have a > separate port for every domain it hosts. exactly. this is one of the many examples where implementations for key SIP specifications don't really exist today. since security seems to rely heavily on SIP/TLS, i would suggest retiring the working group until decent SIP/TLS implementations exits and after that resume the work. -- 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 Mar 14 18:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJJ8B-00081p-9H; Tue, 14 Mar 2006 18:40:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJJ8A-00081k-Jy for sip@ietf.org; Tue, 14 Mar 2006 18:40:46 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJJ87-0001vE-B9 for sip@ietf.org; Tue, 14 Mar 2006 18:40:46 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k2ENecmD038259; Tue, 14 Mar 2006 18:40:42 -0500 (EST) From: "Brett Tate" To: "'Juha Heinanen'" Subject: RE: [Sip] The Problem with PRACK Date: Tue, 14 Mar 2006 18:41:43 -0500 Message-ID: <004301c647c0$da037370$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <17431.17913.375710.846968@rautu.tutpro.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 was just questioning, why do you need to reliable > provisional responses at all, i.e., why all this > complexity introduced by PRACK and UPDATE? They are byproducts of working group decisions related to forking, early media, and offer/answer. The concepts are not overly complex; however there are some common interop problems which I mentioned within the following email. http://www1.ietf.org/mail-archive/web/sip/current/msg13240.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 14 19:07:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJJVn-00025D-Rb; Tue, 14 Mar 2006 19:05:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJJVm-000258-Hu for sip@ietf.org; Tue, 14 Mar 2006 19:05:10 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJJVl-00036A-6j for sip@ietf.org; Tue, 14 Mar 2006 19:05:10 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 8094113F90E; Wed, 15 Mar 2006 02:05:07 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 7915113F637; Wed, 15 Mar 2006 02:04:52 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 1E17AF027E; Wed, 15 Mar 2006 02:05:16 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17431.23100.7622.64935@rautu.tutpro.com> Date: Wed, 15 Mar 2006 02:05:16 +0200 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <39855A1F-58FB-4527-8D53-D0F57AB942CC@softarmor.com> References: <441057B9.8010602@cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F0212E9C4@esebe103.NOE.Nokia.com> <17430.47090.634650.930408@rautu.tutpro.com> <39855A1F-58FB-4527-8D53-D0F57AB942CC@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.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 Dean Willis writes: > Preconditions. They need acknowledgement that the request was > received and acted on by meeting the preconditions at both ends > BEFORE alerting the terminating user. i still don't get it. my UAC does not send an INVITE that would advertise a media that requires more bandwidth than what my current access connection provides. when that INVITE reaches UAS, it would reject the INVITE if it does not have a media listed that would fit into its access connection. why would we need all those new messages and the hassle that comes with them? -- 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 Mar 14 22:23:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJMZa-0002Zd-IY; Tue, 14 Mar 2006 22:21:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJMZZ-0002ZY-Ei for sip@ietf.org; Tue, 14 Mar 2006 22:21:17 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJMZY-0008Kv-3g for sip@ietf.org; Tue, 14 Mar 2006 22:21:17 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 14 Mar 2006 19:21:15 -0800 X-IronPort-AV: i="4.02,192,1139212800"; d="scan'208"; a="1785031115:sNHT31896502" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2F3LCYg027967; Tue, 14 Mar 2006 19:21:15 -0800 (PST) Received: from 128.107.139.201 ([128.107.139.201]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Mar 2006 03:21:12 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 14 Mar 2006 19:21:12 -0800 Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 From: Cullen Jennings To: Hans Persson Message-ID: Thread-Topic: [Sip] SBCs and draft-ietf-sip-identity-06 Thread-Index: AcZH34KKwTYSXbPSEdqfqQARJEEJ/A== In-Reply-To: <1142322506.6820.1.camel@eeek.ingate.se> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 1.6 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "sip@ietf.org" , 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 3/13/06 11:48 PM, "Hans Persson" wrote: > m=E5n 2006-03-13 klockan 22:59 -0800 skrev Cullen Jennings: >=20 >> I doubt that Identity breaks B2BUA in the cases that I have heard of. I >> roughly break the cases into two classes - ones where the B2BUA wants to >> assert a new identity because it is hiding the old one; And cases where = it >> is in the same domain as the original party. In either case the B2BUA ca= n >> have the credentials to be able to re-sign the identity in the message. = I'm >> won't be surprised if someone comes up with a case where it is a problem= but >> so far, everyone I have heard of has not been a problem. >=20 > I'd rather expect problem in the opposite direction. If the B2BUA wants > to terminate incoming calls, then the receiving client won't be able to > verify the identity of the caller since the B2BUA will have modified the > body (at least) of the incoming request since the creation of the > Identity header. >=20 > Hans So call in domain A goes to B2BUA in domain B. B2BUA checks the identity an= d if it is not good, it discards the call. If it likes it the identity, it maps to a name in domain B, signs with credential in domain B, and sends to client in domain B that is trusts credentials in domain B. You are right that the B2BUA need to check the identity for you but that is the nature of anything that changes Identity items. It's not much differnt than the outgoing direction. =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 Mar 14 22:24:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJMag-0002y5-HP; Tue, 14 Mar 2006 22:22:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJMaf-0002xu-VZ for sip@ietf.org; Tue, 14 Mar 2006 22:22:25 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJMae-0008P6-GL for sip@ietf.org; Tue, 14 Mar 2006 22:22:25 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 14 Mar 2006 19:22:24 -0800 X-IronPort-AV: i="4.02,192,1139212800"; d="scan'208"; a="1785031256:sNHT32618884" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2F3MN1j018970; Tue, 14 Mar 2006 19:22:23 -0800 (PST) Received: from 128.107.139.201 ([128.107.139.201]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Mar 2006 03:22:23 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 14 Mar 2006 19:22:23 -0800 Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processingfaster than a SIP PING request processing? From: Cullen Jennings To: "Christer Holmberg (JO/LMF)" , Hisham Khartabil , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processingfaster than a SIP PING request processing? Thread-Index: AcZGEMLnAZKxbbIEEdqjXwARJEEJ/ABU9AmAAB7GdDQ= In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B4D@esealmw113.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 Options would not be forwarded if it was sent to the edge proxy. On 3/14/06 4:48 AM, "Christer Holmberg (JO/LMF)" wrote: > > Hi, > > Without commenting on the "speed" issue, IF we want to use a SIP based > solution I would prefear a dedicated one, instead of re-using OPTIONS. > > Like I said earlier, IF the edge proxy "understands" the mechanism, and > IF it knows the request does not need to be forwarded, it can choose to > terminate it. Yes, it's b2bua behaviour, but still. I do not want a > solution that forces me to overload the rest of the network with the > keep-alive requests - no matter what mechanism is used - and therefor > OPTIONS is not a good solution, because since OPTIONS would also be used > for non-keep-alive purposes it would always have to be forwarded. > > Another solution, as I mentioned earlier, would be that the keep-alives > are addressed to the edge proxy (or whatever entity on the other side of > the NAT). Then it would be "normal SIP", without any b2bua behavior. > > Regards, > > Christer > > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 12. maaliskuuta 2006 22:09 > To: Hisham Khartabil; sip@ietf.org > Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request > processingfaster than a SIP PING request processing? > > > You results don't look right to me. I can't really test very well on my > notebook computer but with STUN on a apple powerbook I am getting 16,000 > TPS at about 30% CPU. Who knows what I could get with an intel processor > :-) Your results look like 6 to 10k TPS. When people quote ms I never > have any clue if they are including the kernel time, it it is a latency > or what. The number we need here is aggregate throughput, not latency so > actual transactions per second on some suitable box might be the easies > to compare. > Similarly, the rates of OPTIONS also looked fairly slow so perhaps I > just don't get what you are measuring. > > Ignoring that, when I look at the code, I can't see any particular > reason that the speed of PING would not be roughly the same as STUN. The > problem is this violates RFC 3261 in so many ways that you can barely > make a list of them all. Once you do the processing to make this > consistent with existing things, the performance will drop significantly > - my guess is that it would drop to roughly the same rate as OPTION. > > > On 3/6/06 10:02 AM, "Hisham Khartabil" > wrote: > >> I promised to come back with hard real numbers on how long it will >> take for a server to process and STUN request vs a SIP PING request >> >> Myth: processing a STUN request is 10 to 100 times faster than a SIP >> PING request >> >> Assumptions: - SIP PING request is processed early in the stack and >> bypasses any unnecessary validations. >> - SIP PING response carries in the contact header the >> IP address and port as appears in the IP packet (source IP and port). >> >> We implemented the PING request as described above in the reSIProcate >> stack. Attached you will find the c++ file where the changes were > made. >> STUN was already implemented in the reSIProcate stack and used as is. >> >> Below you will see the findings: >> >> STUN request processing: 0.15 - 0.2 ms SIP PING request processing: >> 0.1 - 0.2 ms SIP OPTIONS request: 7 ms SIP REGISTER request: 7 ms >> >> The measurement was taken between the time a request appeared on >> ethereal and its response appearing on ethereal. Average was taken >> manually. >> >> As you can see, SIP PING requests were sometimes faster to process >> that STUN requests, but never slower. Actually the SIP PING requests >> on average were faster to process. >> >> Myth Busted!!!! :) >> >> Regards, >> Hisham >> P.S. It took 15 mins to modify the sip stack to do the PING response. >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 15 01:25:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJPPz-00050W-GW; Wed, 15 Mar 2006 01:23:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJPPZ-0004ne-Vt for sip@ietf.org; Wed, 15 Mar 2006 01:23:09 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJPLC-0004ZQ-Ll for sip@ietf.org; Wed, 15 Mar 2006 01:18:40 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2F6IWl17636; Wed, 15 Mar 2006 01:18:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? Date: Wed, 15 Mar 2006 00:18:29 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AE06946@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? Thread-Index: AcZGEMLnAZKxbbIEEdqjXwARJEEJ/ABU9AmAAB7GdDQABQFSYA== From: "Samir Srivastava" To: "Cullen Jennings" , "Christer Holmberg \(JO/LMF\)" , "Hisham Khartabil" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 We cannot differentiate whether OPTIONS is for keep alive or for other purpose without parsing it=20 completely. It might have Require and Proxy Require too. That was the sole purpose of dedicated new message. How gaming protocols use STUN i.e. muxing, keep alives ? We might have Gaming Application and SIP UA on the same physical Device. Thx Samir -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Tuesday, March 14, 2006 7:22 PM To: Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? Options would not be forwarded if it was sent to the edge proxy. On 3/14/06 4:48 AM, "Christer Holmberg (JO/LMF)" wrote: >=20 > Hi, >=20 > Without commenting on the "speed" issue, IF we want to use a SIP based > solution I would prefear a dedicated one, instead of re-using OPTIONS. >=20 > Like I said earlier, IF the edge proxy "understands" the mechanism,=20 > and IF it knows the request does not need to be forwarded, it can=20 > choose to terminate it. Yes, it's b2bua behaviour, but still. I do not > want a solution that forces me to overload the rest of the network=20 > with the keep-alive requests - no matter what mechanism is used - and=20 > therefor OPTIONS is not a good solution, because since OPTIONS would=20 > also be used for non-keep-alive purposes it would always have to be forwarded. >=20 > Another solution, as I mentioned earlier, would be that the=20 > keep-alives are addressed to the edge proxy (or whatever entity on the > other side of the NAT). Then it would be "normal SIP", without any b2bua behavior. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 12. maaliskuuta 2006 22:09 > To: Hisham Khartabil; sip@ietf.org > Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request=20 > processingfaster than a SIP PING request processing? >=20 >=20 > You results don't look right to me. I can't really test very well on=20 > my notebook computer but with STUN on a apple powerbook I am getting=20 > 16,000 TPS at about 30% CPU. Who knows what I could get with an intel=20 > processor > :-) Your results look like 6 to 10k TPS. When people quote ms I never=20 > have any clue if they are including the kernel time, it it is a=20 > latency or what. The number we need here is aggregate throughput, not=20 > latency so actual transactions per second on some suitable box might=20 > be the easies to compare. > Similarly, the rates of OPTIONS also looked fairly slow so perhaps I=20 > just don't get what you are measuring. >=20 > Ignoring that, when I look at the code, I can't see any particular=20 > reason that the speed of PING would not be roughly the same as STUN.=20 > The problem is this violates RFC 3261 in so many ways that you can=20 > barely make a list of them all. Once you do the processing to make=20 > this consistent with existing things, the performance will drop=20 > significantly > - my guess is that it would drop to roughly the same rate as OPTION. >=20 >=20 > On 3/6/06 10:02 AM, "Hisham Khartabil" > wrote: >=20 >> I promised to come back with hard real numbers on how long it will=20 >> take for a server to process and STUN request vs a SIP PING request >>=20 >> Myth: processing a STUN request is 10 to 100 times faster than a SIP=20 >> PING request >>=20 >> Assumptions: - SIP PING request is processed early in the stack and=20 >> bypasses any unnecessary validations. >> - SIP PING response carries in the contact header the=20 >> IP address and port as appears in the IP packet (source IP and port). >>=20 >> We implemented the PING request as described above in the reSIProcate >> stack. Attached you will find the c++ file where the changes were > made. >> STUN was already implemented in the reSIProcate stack and used as is. >>=20 >> Below you will see the findings: >>=20 >> STUN request processing: 0.15 - 0.2 ms SIP PING request processing: >> 0.1 - 0.2 ms SIP OPTIONS request: 7 ms SIP REGISTER request: 7 ms >>=20 >> The measurement was taken between the time a request appeared on=20 >> ethereal and its response appearing on ethereal. Average was taken=20 >> manually. >>=20 >> As you can see, SIP PING requests were sometimes faster to process=20 >> that STUN requests, but never slower. Actually the SIP PING requests=20 >> on average were faster to process. >>=20 >> Myth Busted!!!! :) >>=20 >> Regards, >> Hisham >> P.S. It took 15 mins to modify the sip stack to do the PING response. >>=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 15 01:57:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJPv0-0001HC-0o; Wed, 15 Mar 2006 01:55:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJPu7-0000kp-5j for sip@ietf.org; Wed, 15 Mar 2006 01:54:43 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJPk2-00052e-A6 for sip@ietf.org; Wed, 15 Mar 2006 01:44:19 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2F6iEGS030535; Wed, 15 Mar 2006 08:44:14 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 08:44:12 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 08:44: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 08:44:13 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0212ED79@esebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHrukShmux3WWcRXW7MqiteVC/KwATG8mQ From: To: , , X-OriginalArrivalTime: 15 Mar 2006 06:44:13.0188 (UTC) FILETIME=[DF17CC40:01C647FB] X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 ! > As has been said before, I don't think the precondition=20 > mechanism mandates the usage of PRACK for offer/answer. I agree with you. But this far it has been possible and there are implementations using that option, for specific reasons. I did not intend to tell more than that and still think it was relevant input for this discussion. Thanks, Erkki=20 >-----Original Message----- >From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 >Sent: 14.March.2006 23:28 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki);=20 >pkyzivat@cisco.com; princeap@gmail.com >Cc: sip@ietf.org >Subject: RE: [Sip] The Problem with PRACK > >Hi, > >As has been said before, I don't think the precondition=20 >mechanism mandates the usage of PRACK for offer/answer. > >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 Mar 15 02:13:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQAE-0008Jg-Rz; Wed, 15 Mar 2006 02:11:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQAD-0008Jb-8Z for sip@ietf.org; Wed, 15 Mar 2006 02:11:21 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJQAA-00067c-Ce for sip@ietf.org; Wed, 15 Mar 2006 02:11:21 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DC11A4F000B; Wed, 15 Mar 2006 08:11:17 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 08:11:17 +0100 Received: from [136.225.183.82] ([136.225.183.82]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 08:11:14 +0100 From: "Christer Holmberg" To: Erkki.Koivusalo@nokia.com, pkyzivat@cisco.com, princeap@gmail.com Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 09:06:22 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 15 Mar 2006 07:11:17.0118 (UTC) FILETIME=[A707D9E0:01C647FF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, For my clarification, how do the implementations you are talking about = REJECT an offer received in PRACK? Regards, Christe _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 15 02:14:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQBL-0000Up-PS; Wed, 15 Mar 2006 02:12:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQBJ-0000Uk-Mp for sip@ietf.org; Wed, 15 Mar 2006 02:12:29 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJQBH-00069p-5b for sip@ietf.org; Wed, 15 Mar 2006 02:12:29 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 28CD5DA8; Wed, 15 Mar 2006 08:11:08 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 08:11:07 +0100 Received: from [136.225.183.82] ([136.225.183.82]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 08:11:04 +0100 From: "Christer Holmberg" To: "Cullen Jennings" , "Hisham Khartabil" , "sip@ietf.org" Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processingfaste r than a SIP PING request processing? Date: Wed, 15 Mar 2006 09:06:13 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 15 Mar 2006 07:11:07.0368 (UTC) FILETIME=[A1381E80:01C647FF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Ok, but that assumes the UAC somehow is told to addree the request to the = proxy, instead of the reote user. Right? 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 Mar 15 02:26:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQMe-0006kU-3Q; Wed, 15 Mar 2006 02:24:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQMc-0006jq-1G for sip@ietf.org; Wed, 15 Mar 2006 02:24:10 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJQMa-0006eX-Iy for sip@ietf.org; Wed, 15 Mar 2006 02:24:10 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2F7M7or032027; Wed, 15 Mar 2006 09:22:09 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 09:24:01 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 09:24:02 +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] The Problem with PRACK Date: Wed, 15 Mar 2006 09:24:01 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0212EDE9@esebe103.NOE.Nokia.com> In-Reply-To: <17431.23100.7622.64935@rautu.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHxPrzvcI1kVE0QF+vBPtruuhjtQAPACag From: To: , X-OriginalArrivalTime: 15 Mar 2006 07:24:02.0283 (UTC) FILETIME=[6F1AC3B0:01C64801] X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.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, In 3G networks the access connections are reserved dynamically (call by call basis). Preconditions are used to make sure that the callee will be alerted only if the network was able to reserve the needed bandwidth for both the users. Otherwise it would be possible that the phone could start ringing and the callee would answer it, but the network failed to provide=20 the needed bandwidth for media and the call fails. Regards, Erkki >-----Original Message----- >From: ext Juha Heinanen [mailto:jh@tutpro.com]=20 >Sent: 15.March.2006 02:05 >To: Dean Willis >Cc: sip@ietf.org; pkyzivat@cisco.com; princeap@gmail.com >Subject: Re: [Sip] The Problem with PRACK > >Dean Willis writes: > > > Preconditions. They need acknowledgement that the request was =20 > > received and acted on by meeting the preconditions at both ends =20 > > BEFORE alerting the terminating user. > >i still don't get it. my UAC does not send an INVITE that would >advertise a media that requires more bandwidth than what my current >access connection provides. when that INVITE reaches UAS, it would >reject the INVITE if it does not have a media listed that=20 >would fit into >its access connection. why would we need all those new=20 >messages and the >hassle that comes with them? > >-- 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 Wed Mar 15 02:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQhK-00070I-5X; Wed, 15 Mar 2006 02:45:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQhI-0006xY-94 for sip@ietf.org; Wed, 15 Mar 2006 02:45:32 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJQhE-0006y1-EV for sip@ietf.org; Wed, 15 Mar 2006 02:45:32 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by test-iport-1.cisco.com with ESMTP; 14 Mar 2006 23:45:27 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2F7jR1j028800; Tue, 14 Mar 2006 23:45:27 -0800 (PST) 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.211); Tue, 14 Mar 2006 23:45:27 -0800 Received: from [10.21.147.125] ([10.21.147.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 23:45:26 -0800 Message-ID: <4417C616.3010904@cisco.com> Date: Wed, 15 Mar 2006 02:45:26 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] The Problem with PRACK References: <5EB80D22825EEE42872083AD5BFFB5945D1B4F@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B4F@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2006 07:45:26.0872 (UTC) FILETIME=[6CC77D80:01C64804] X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: IETF SIP List , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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, > > An answer can always be sent in the ACK, but the problem is if we want > to send it earlier. > > I also agree that if a device does not support an offer in a PRACK it's > a bug. > > HOWEVER, the standard does not specify how an offer in a PRACK is > rejected. This has been discussed before, I don't recall that. When and where was it discussed? I'm not sure I see a real problem here. An offer in a prack can't be the first offer. As a subsequent offer, it is constrained it what it can contain in such a way that the answer should always be able to achieve something tolerable, if not desirable. > and one possible solution was > that the 200 OK would not contain an SDP, and that would mean the offer > was rejected. That is not specified behavior, however. This seems like a largely separate discussion to have. Paul > Regards, > > Christer > > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 9. maaliskuuta 2006 1:43 > To: Brett Tate > Cc: 'IETF SIP List' > Subject: Re: [Sip] The Problem with PRACK > > > > Brett Tate wrote: > >>>So, I'd like to discuss exactly what IS the problem with PRACK? There >>>are really two pieces of state machinery in play here. One piece is >>>the complication that PRACK introduces into the offer/answer model. >>>With PRACK, you can now get a final answer in the 18x, and then send a > > >>>new offer in UPDATE, or even in PRACK itself. >> >> >>An offer within the prack is a pain and potentially a little under >>specified. >> >>One problem is that some devices don't support receiving prack with an > > >>offer. > > > There are lots of things that some devices don't support. > We call those cases BUGS. > > Which devices are those? > > >>Thus the sender needs to handle PRACK 200 without SDP and handle a >>failure response because of the sdp. > > > Are you suggesting that it is *legal* to: > - support PRACK > - not support PRACK with sdp? > > I don't think that is valid. Prack use is enabled via the 100rel option. > > I'm pretty sure that option comes with the whole boat. > > >>And if the UAS does not accept the >>offer, some vendors return 488/606 type responses; others return 200 >>without SDP. >> >>I prefer removing ability for prack to contain an offer. However >>leaving it is ok if vendors who send it can deal with the typical > > interop problems. > > You only want to remove ability for it to contain an offer, but allow it > to contain an answer? Or remove support for both offer and answer? > > As I noted in earlier reply, if we were to do that, then how do you > answer an offer that comes in a reliable provisional response? > > Any change in this stuff has backward compatibility issues. It would > require use of new option tags, and even more complex support than the > existing situation does. > > Paul > > >>>Another piece is the state machinery with the retransmissions itself - > > >>>correlating the PRACK with a particular reliable provisional response >>>and causing it to stop. >> >> >>I'm not aware of this being very complicated. >> >> >> >> >>>Why not revise PRACK so that you can't send an >>>offer or answer with it; it has no impact on the >>>set of allowed O/A exchanges defined by RFC 3261. >>>I'm not sure if that would consequently break the >>>preconditions mechanism, but maybe there are some >>>kind of offer/answer limitations that would simplify >>>things. >> >> >>Answer within prack is needed unless willing to allow subsequent > > different > >>offer from the uas (UPDATE; and maybe other 18x and 2xx) to still > > override > >>first 18x offer. >> >> >> >> >>>So, this is one idea. I'd like for people who have >>>complained about PRACK implementations to speak up >>>and indicate what exactly makes it so complicated >>>for them. >> >> >>It isn't complicated. It is just a matter of getting it implemented > > and > >>deployed; and dealing with the various interoperability pains. (BTW >>draft-sawada-sipping-sip-offeranswer has been a good reference for > > answering > >>many of the common questions about offer/answer within sip; hopefully > > the > >>draft gets adopted by sipping or sip.) >> >>One reason devices don't (or quit) supporting 100rel was because of > > the > >>SHOULDs/MUSTs related to offer/answer. Another reason is because of > > the > >>extra messaging. >> >>And because subsequent SDPs sent within INVITE 18x/2xx no longer have >>precedent over the prior SDP, interoperability is a pain. The UAS now >>requires rfc3311 and rfc3262 support, and/or ability for UAC to > > finally > >>support forking interactions (18x/2xx with different tags). >> >> >>The following are a few random things currently not resolved and/or > > clearly > >>specified. Others are just some random thoughts/rants concerning >>interoperability. >> >>1) Dealing with 18x offer/answer rules with timer c is under > > specified. > >>Should the periodic 18x contain an SDP again? And if so, which one if >>another sent in UPDATE, PRACK, or their responses? >> >>2) RFC3261 discusses possibility of sending SDP again in INVITE 200 >>response. And it says it must be same as prior 18x SDP. However I > > assume > >>if some send it (for backwards compatibility reasons), UAS should send > > the > >>latest correct SDP (if different SDP sent in UPDATE, PRACK response, > > or > >>UPDATE response). >> >>3) A forking proxy currently has no mechanism to indicate to uac when > > a > >>branch has been terminated. Thus the UAC is currently unable to > > easily > >>determine which early dialogs have disappeared. Hopefully this >>functionality will get resolved/included within herfp or another > > draft. > >>4) Concerning UPDATE and SDP, some vendors think SDP is required. And > > some > >>vendors can't handle receiving the 504 response mentioned within > > rfc3311 > >>without releasing the call. >> >>5) "audit" with sdp is pain (especially when prior "answer" becomes > > "offer" > >>within audit). This is mainly just a pain to B2BUAs. Hopefully more >>devices will start correctly support receiving UPDATE without SDP. >> >>6) Some devices still do not support forking proxy interactions very > > well > >>because some B2BUAs reduced the need. And because of all the current >>offer/answer rules, devices expecting correct offer/answer behavior > > need to > >>interact well with forking proxies. I mention this because if a UAS > > needs > >>to update the SDP and can't (because of offer/answer rules, etcetera), > > it > >>might act like forking occurred and send a 18x/2xx with a different > > tag. > >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 15 02:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQmL-0001Oo-S0; Wed, 15 Mar 2006 02:50:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQmK-0001Oj-IO for sip@ietf.org; Wed, 15 Mar 2006 02:50:44 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJQmG-00073B-2k for sip@ietf.org; Wed, 15 Mar 2006 02:50:44 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k2F7oTu0020788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Mar 2006 08:50:29 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k2F7oO5G010297; Wed, 15 Mar 2006 08:50:24 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k2F7oJoI010295; Wed, 15 Mar 2006 08:50:19 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 From: Hans Persson To: Cullen Jennings In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Wed, 15 Mar 2006 08:50:18 +0100 Message-Id: <1142409018.9422.12.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Wed, 15 Mar 2006 08:50:30 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "sip@ietf.org" , 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 tis 2006-03-14 klockan 19:21 -0800 skrev Cullen Jennings: > So call in domain A goes to B2BUA in domain B. B2BUA checks the identity and > if it is not good, it discards the call. If it likes it the identity, it > maps to a name in domain B, signs with credential in domain B, and sends to > client in domain B that is trusts credentials in domain B. You are right > that the B2BUA need to check the identity for you but that is the nature of > anything that changes Identity items. It's not much differnt than the > outgoing direction. This sounds weird. A call from domain A (say fluffy@cisco.com) comes in to B2BUA. B2BUA checks the identity and finds that you are who you claim to be. So far, so good. What do you mean by "maps to a name in domain B"? Should the B2BUA change the call to appear to come from fluffy@ingate.com, sign that, and forward the call? That sounds like a really bad idea. In many cases, there will be no association between the domain of the caller and the domain of the called, so it's not possible to resign the request when it gets forwarded (the B2BUA won't be able to sign for the calling domain). tis 2006-03-14 klockan 15:22 -0600 skrev Dean Willis: > yes, that's exactly the case I was worrying over. At the best, the > SBC can tell the terminating UA what the identity it received was and > claim to have checked that identity on behalf of the terminating UA. > This is in effect a new assertion of identity, based on a transitive > trust agreement. Yes. What we need is a way to forward the fact that the identity has been asserted at a hop before the end client, but within the same domain. P-Asserted-From? Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 15 03:21:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRDv-0005Sk-8T; Wed, 15 Mar 2006 03:19:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJR9C-0003qK-Sz for sip@ietf.org; Wed, 15 Mar 2006 03:14:22 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJR1p-0007hw-Tz for sip@ietf.org; Wed, 15 Mar 2006 03:06:47 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2F86hiB028916; Wed, 15 Mar 2006 10:06:43 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 10:06:43 +0200 Received: from [172.21.38.173] ([172.21.38.173]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Mar 2006 10:06:42 +0200 Message-ID: <4417CB11.50205@nokia.com> Date: Wed, 15 Mar 2006 10:06:41 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Hans Persson Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 References: <1142409018.9422.12.camel@eeek.ingate.se> In-Reply-To: <1142409018.9422.12.camel@eeek.ingate.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2006 08:06:42.0324 (UTC) FILETIME=[65020540:01C64807] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Cullen Jennings , "sip@ietf.org" , 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 Hans Persson wrote: > This sounds weird. A call from domain A (say fluffy@cisco.com) comes in > to B2BUA. B2BUA checks the identity and finds that you are who you claim > to be. So far, so good. > > What do you mean by "maps to a name in domain B"? Should the B2BUA > change the call to appear to come from fluffy@ingate.com, sign that, and > forward the call? That sounds like a really bad idea. Well, you can't have sip-identity and break it at the same time. Choose your poison. > Yes. What we need is a way to forward the fact that the identity has > been asserted at a hop before the end client, but within the same > domain. P-Asserted-From? I think RFC3325 is enough. 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 Wed Mar 15 03:44:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRaC-0007zb-QH; Wed, 15 Mar 2006 03:42:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRaA-0007zW-Uw for sip@ietf.org; Wed, 15 Mar 2006 03:42:14 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJRa9-0000Py-K3 for sip@ietf.org; Wed, 15 Mar 2006 03:42:14 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 404381403F8; Wed, 15 Mar 2006 10:42:12 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id D7C041403ED; Wed, 15 Mar 2006 10:42:01 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 36982F027F; Wed, 15 Mar 2006 10:42:19 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17431.54123.106216.734949@rautu.tutpro.com> Date: Wed, 15 Mar 2006 10:42:19 +0200 From: Juha Heinanen To: Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0212EDE9@esebe103.NOE.Nokia.com> References: <17431.23100.7622.64935@rautu.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F0212EDE9@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.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 Erkki.Koivusalo@nokia.com writes: > In 3G networks the access connections are reserved dynamically > (call by call basis). Preconditions are used to make sure that > the callee will be alerted only if the network was able to > reserve the needed bandwidth for both the users. Otherwise > it would be possible that the phone could start ringing and > the callee would answer it, but the network failed to provide > the needed bandwidth for media and the call fails. still don't get it. why can't the 3g proxy allocate bandwidth for the highest bandwidth codec in the invite? -- 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 Mar 15 03:53:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRjO-000440-0s; Wed, 15 Mar 2006 03:51:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRjM-00043q-GN for sip@ietf.org; Wed, 15 Mar 2006 03:51:44 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJRjL-0000eZ-5f for sip@ietf.org; Wed, 15 Mar 2006 03:51:44 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 846ED1403F8; Wed, 15 Mar 2006 10:51:42 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 2D6C71403ED; Wed, 15 Mar 2006 10:51:32 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id E461BF027F; Wed, 15 Mar 2006 10:51:58 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17431.54702.803803.907459@rautu.tutpro.com> Date: Wed, 15 Mar 2006 10:51:58 +0200 From: Juha Heinanen To: , sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.com, dean.willis@softarmor.com Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <17431.54123.106216.734949@rautu.tutpro.com> References: <17431.23100.7622.64935@rautu.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F0212EDE9@esebe103.NOE.Nokia.com> <17431.54123.106216.734949@rautu.tutpro.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 Juha Heinanen writes: > still don't get it. why can't the 3g proxy allocate bandwidth for the > highest bandwidth codec in the invite? ... and then possibly reduce the allocation when 200 OK comes back or remove the allocation completely if something else comes back. -- 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 Mar 15 03:54:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRkI-0004jg-1g; Wed, 15 Mar 2006 03:52:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRkG-0004fw-CR for sip@ietf.org; Wed, 15 Mar 2006 03:52:40 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJRkF-0000fq-CW for sip@ietf.org; Wed, 15 Mar 2006 03:52:40 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CB0A3C7D; Wed, 15 Mar 2006 09:52:38 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 09:52:38 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 09:52:37 +0100 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] The Problem with PRACK Date: Wed, 15 Mar 2006 09:52:36 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B54@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIBHCTh6whJREeQiWTk8dwuX0t9wACQacg From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 15 Mar 2006 08:52:37.0598 (UTC) FILETIME=[CF4777E0:01C6480D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Cc: IETF SIP List , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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 >An answer can always be sent in the ACK, but the problem is if we want=20 >to send it earlier. >=20 >I also agree that if a device does not support an offer in a PRACK=20 >it's a bug. >=20 >HOWEVER, the standard does not specify how an offer in a PRACK is=20 >rejected. This has been discussed before, I don't recall that. When and where was it discussed? [CHH] It was a while ago. I THINK it was on the implementors list. I'm not sure I see a real problem here. An offer in a prack can't be the first offer. As a subsequent offer, it is constrained it what it can contain in such a way that the answer should always be able to achieve something tolerable, if not desirable. [CHH] In theory, the offer could contain one or more new streams. But, there can also be a technical reason why the receiver simply isn't capable of processing the offer at the time it is received. In any case, I don't a solution where one isn't able to reject an offer - for whatever reason... Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 9. maaliskuuta 2006 1:43 > To: Brett Tate > Cc: 'IETF SIP List' > Subject: Re: [Sip] The Problem with PRACK >=20 >=20 >=20 > Brett Tate wrote: >=20 >>>So, I'd like to discuss exactly what IS the problem with PRACK? There >>>are really two pieces of state machinery in play here. One piece is=20 >>>the complication that PRACK introduces into the offer/answer model. >>>With PRACK, you can now get a final answer in the 18x, and then send=20 >>>a >=20 >=20 >>>new offer in UPDATE, or even in PRACK itself. >> >> >>An offer within the prack is a pain and potentially a little under=20 >>specified. >> >>One problem is that some devices don't support receiving prack with an >=20 >=20 >>offer. >=20 >=20 > There are lots of things that some devices don't support. > We call those cases BUGS. >=20 > Which devices are those? >=20 >=20 >>Thus the sender needs to handle PRACK 200 without SDP and handle a=20 >>failure response because of the sdp. >=20 >=20 > Are you suggesting that it is *legal* to: > - support PRACK > - not support PRACK with sdp? >=20 > I don't think that is valid. Prack use is enabled via the 100rel option. >=20 > I'm pretty sure that option comes with the whole boat. >=20 >=20 >>And if the UAS does not accept the >>offer, some vendors return 488/606 type responses; others return 200=20 >>without SDP. >> >>I prefer removing ability for prack to contain an offer. However=20 >>leaving it is ok if vendors who send it can deal with the typical >=20 > interop problems. >=20 > You only want to remove ability for it to contain an offer, but allow=20 > it to contain an answer? Or remove support for both offer and answer? >=20 > As I noted in earlier reply, if we were to do that, then how do you=20 > answer an offer that comes in a reliable provisional response? >=20 > Any change in this stuff has backward compatibility issues. It would=20 > require use of new option tags, and even more complex support than the > existing situation does. >=20 > Paul >=20 >=20 >>>Another piece is the state machinery with the retransmissions itself=20 >>>- >=20 >=20 >>>correlating the PRACK with a particular reliable provisional response >>>and causing it to stop. >> >> >>I'm not aware of this being very complicated. >> >> >> >> >>>Why not revise PRACK so that you can't send an offer or answer with=20 >>>it; it has no impact on the set of allowed O/A exchanges defined by=20 >>>RFC 3261. >>>I'm not sure if that would consequently break the preconditions=20 >>>mechanism, but maybe there are some kind of offer/answer limitations=20 >>>that would simplify things. >> >> >>Answer within prack is needed unless willing to allow subsequent >=20 > different >=20 >>offer from the uas (UPDATE; and maybe other 18x and 2xx) to still >=20 > override >=20 >>first 18x offer. >> >> >> >> >>>So, this is one idea. I'd like for people who have complained about=20 >>>PRACK implementations to speak up and indicate what exactly makes it=20 >>>so complicated for them. >> >> >>It isn't complicated. It is just a matter of getting it implemented >=20 > and >=20 >>deployed; and dealing with the various interoperability pains. (BTW=20 >>draft-sawada-sipping-sip-offeranswer has been a good reference for >=20 > answering >=20 >>many of the common questions about offer/answer within sip; hopefully >=20 > the >=20 >>draft gets adopted by sipping or sip.) >> >>One reason devices don't (or quit) supporting 100rel was because of >=20 > the >=20 >>SHOULDs/MUSTs related to offer/answer. Another reason is because of >=20 > the >=20 >>extra messaging. >> >>And because subsequent SDPs sent within INVITE 18x/2xx no longer have=20 >>precedent over the prior SDP, interoperability is a pain. The UAS now >>requires rfc3311 and rfc3262 support, and/or ability for UAC to >=20 > finally >=20 >>support forking interactions (18x/2xx with different tags). >> >> >>The following are a few random things currently not resolved and/or >=20 > clearly >=20 >>specified. Others are just some random thoughts/rants concerning=20 >>interoperability. >> >>1) Dealing with 18x offer/answer rules with timer c is under >=20 > specified. >=20 >>Should the periodic 18x contain an SDP again? And if so, which one if >>another sent in UPDATE, PRACK, or their responses? >> >>2) RFC3261 discusses possibility of sending SDP again in INVITE 200=20 >>response. And it says it must be same as prior 18x SDP. However I >=20 > assume >=20 >>if some send it (for backwards compatibility reasons), UAS should send >=20 > the >=20 >>latest correct SDP (if different SDP sent in UPDATE, PRACK response, >=20 > or >=20 >>UPDATE response). >> >>3) A forking proxy currently has no mechanism to indicate to uac when >=20 > a >=20 >>branch has been terminated. Thus the UAC is currently unable to >=20 > easily >=20 >>determine which early dialogs have disappeared. Hopefully this=20 >>functionality will get resolved/included within herfp or another >=20 > draft. >=20 >>4) Concerning UPDATE and SDP, some vendors think SDP is required. And >=20 > some >=20 >>vendors can't handle receiving the 504 response mentioned within >=20 > rfc3311 >=20 >>without releasing the call. >> >>5) "audit" with sdp is pain (especially when prior "answer" becomes >=20 > "offer" >=20 >>within audit). This is mainly just a pain to B2BUAs. Hopefully more=20 >>devices will start correctly support receiving UPDATE without SDP. >> >>6) Some devices still do not support forking proxy interactions very >=20 > well >=20 >>because some B2BUAs reduced the need. And because of all the current=20 >>offer/answer rules, devices expecting correct offer/answer behavior >=20 > need to >=20 >>interact well with forking proxies. I mention this because if a UAS >=20 > needs >=20 >>to update the SDP and can't (because of offer/answer rules, etcetera), >=20 > it >=20 >>might act like forking occurred and send a 18x/2xx with a different >=20 > tag. >=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=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 Mar 15 03:55:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRlf-00069E-8f; Wed, 15 Mar 2006 03:54:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCnY-0002hq-5a for sip@ietf.org; Tue, 14 Mar 2006 11:55:04 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJCnX-00071B-Qk for sip@ietf.org; Tue, 14 Mar 2006 11:55:04 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2EGt0801866; Tue, 14 Mar 2006 11:55:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Tue, 14 Mar 2006 10:54:59 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710D67DA69@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHOHchwiZepEnEQKyOIw4lVBiYVQATjQNA From: "Brian Stucker" To: "Dean Willis" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Wed, 15 Mar 2006 03:54:05 -0500 Cc: sip@ietf.org, Francois Audet , Paul H 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 Based on your proposals below, cryptographically transparent versus = redirection: How would you go about addressing applications like CPL that need to run = timers for service logic and thus need to have some level of control = over the session (not necessarily what's in the body of the messages, = just where they're going) if a redirection model is used? For example, without mucking about with what's inside the request, = triggering off of the request URI of an INVITE to forward to destination = A for X seconds and then to destination B. In this example the next hop = changes over time for the same request and does not seem possible using = redirection. This seems to preclude redirection as a general solution = and drive towards requiring a proxy to be cryptographically transparent. If the proxy is transparent, then how do you go about not precluding = deep-packet inspection issues raised by applications such as QoS = enforcement, network enforced identity or other services? It seems to me = that HTTPS may make a bad model in that I'm unaware of any HTTPS-based = application that has a box in the middle that needs to inspect and = enforce certain characteristics of the request before it is handled by = the final consumer of that request. This seems to preclude cryptographic transparency as a general solution. = I'm sure either can be used effectively in many application spaces, but = it does not seem that either can be used as a general solution in the = protocol itself. Regards, Brian -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, March 14, 2006 1:08 AM To: Cullen Jennings Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul H Kyzivat Subject: Re: [Sip] The Problem with PRACK On Mar 14, 2006, at 12:24 AM, Cullen Jennings wrote: > On 3/13/06 10:27 AM, "Dean Willis" wrote: > >> Right. But, SIPS is only required as far as the proxy serving the >> AOR. The AOR to Contact vector could be UDP/IPSEC, or even just plain >> unsecured UDP. > > I think we have a gathering amount of evidence that we want to =20 > update this > regardless of UDP or PRACK. It's true that SIP proxies just don't work "right" with SIPS as it is. When people first look at the "SIPS is only valid to the serving =20 proxy" model they assume that simply changing the requirement to say =20 that the proxy-to-UA leg must also be SIPS protected would provide a =20 satisfactory answer. It doesn't, and this requires some careful =20 thinking. What security do you mandate on the serving-proxy to UA link? TLS? =20 TLS supports many different ciphersuites. What keeps the crypto on =20 the SP-UA link from being watered-down? Would other protections like =20 IPSEC suffice? How would you end-to-end negotiate the cryptography so =20 that the originating UA could believe that the entire chain was =20 protected to some minimal level? And how do you offer some level of =20 security to an IMS fashion-victim who is always going to be exposed =20 to MITM attacks from his own service provider by design? Personally, I think the only way SIPS really gives us the level of =20 protection we have come to expect from HTTPS is if it is used end-to-=20 end, either by abandoning proxy-routing in favor of a redirect model, =20 or by causing the proxies to be cryptographically transparent as is =20 done with HTTPS proxies. This is an important thing to note: HTTPS proxies do NOT "see inside" =20 the HTTPS stream. All they do is pass it along, unchanged, to the =20 next hop. It could actually be some other protocol than HTTP, and =20 they don't care and can't tell. To-date, we haven't treated SIPS =20 proxies that way, and instead presume they have access to the full =20 stream, in many cases "write access" so that they can munge various =20 header fields about. -- 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 Wed Mar 15 03:57:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRmq-0007Hg-GA; Wed, 15 Mar 2006 03:55:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRmo-0007Hb-Ty for sip@ietf.org; Wed, 15 Mar 2006 03:55:18 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJRmn-0000ti-J4 for sip@ietf.org; Wed, 15 Mar 2006 03:55:18 -0500 Received: by tutpro.com (Postfix, from userid 65534) id E452A1403F8; Wed, 15 Mar 2006 10:55:16 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 6D5D61403F3; Wed, 15 Mar 2006 10:55:06 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id D9624F0280; Wed, 15 Mar 2006 10:55:29 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17431.54913.828994.533928@rautu.tutpro.com> Date: Wed, 15 Mar 2006 10:55:29 +0200 From: Juha Heinanen To: Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0212ED79@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0212ED79@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.com, christer.holmberg@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 Erkki.Koivusalo@nokia.com writes: > I agree with you. But this far it has been possible and > there are implementations using that option, for specific > reasons. I did not intend to tell more than that and still > think it was relevant input for this discussion. my suggestion is that PRACK is deprecated and if mobile vendors still need it, they can solve the problems on 3gpp mailing lists. -- 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 Mar 15 04:08:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRxn-0004K4-Bk; Wed, 15 Mar 2006 04:06:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRxl-0004Jy-NB for sip@ietf.org; Wed, 15 Mar 2006 04:06:37 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJRxk-0001eL-7Y for sip@ietf.org; Wed, 15 Mar 2006 04:06:37 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9F3E04F0001; Wed, 15 Mar 2006 10:06:35 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 10:06:35 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 10:06:35 +0100 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] The Problem with PRACK Date: Wed, 15 Mar 2006 10:06:34 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B55@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIDc+RWH5GLOWLQu20nXGoI11+PgAASXQg From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , , , , , X-OriginalArrivalTime: 15 Mar 2006 09:06:35.0110 (UTC) FILETIME=[C279A860:01C6480F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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, A simple use-case, not necessarily related only to 3G, is when one wants only to use a single codec. The UAC then send his lists of codecs, gets back the UAS list of codecs, and then send a new offer with only one codec both supports. Because, unfortunately there is no mechanism in SIP/SDP to say: "here is my list of codecs, please choose one (or whatever number)". In H.248 we DO have that capability, using the ReserveValue/Group properties ;) Another use-case is where the first offer indicates "inactive", e.g. because of radio bearer and/or other resource reasons, and then want to be able to change that to "sendrecv" before 200 OK. Regards, Christer=20 -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 15. maaliskuuta 2006 10:52 To: Erkki.Koivusalo@nokia.com; sip@ietf.org; pkyzivat@cisco.com; princeap@gmail.com; dean.willis@softarmor.com Subject: RE: [Sip] The Problem with PRACK Juha Heinanen writes: > still don't get it. why can't the 3g proxy allocate bandwidth for the > highest bandwidth codec in the invite? ... and then possibly reduce the allocation when 200 OK comes back or remove the allocation completely if something else comes back. -- 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 Wed Mar 15 04:15:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJS4P-000874-Ka; Wed, 15 Mar 2006 04:13:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJS4O-00085Z-ID for sip@ietf.org; Wed, 15 Mar 2006 04:13:28 -0500 Received: from sedna.sxdesign.com ([193.71.196.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJS4M-0001tb-5h for sip@ietf.org; Wed, 15 Mar 2006 04:13:28 -0500 Received: from 2.80-203-147.nextgentel.com ([80.203.147.2] helo=[10.47.0.2]) by sedna.sxdesign.com with esmtpa (Exim 4.50) id 1FJS4K-0002AK-9S for sip@ietf.org; Wed, 15 Mar 2006 10:13:24 +0100 Message-ID: <4417DAB2.30201@owera.com> Date: Wed, 15 Mar 2006 10:13:22 +0100 From: Richard Aas Organization: SX Design User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Sip] Selecting a Transport 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 all, I need some clarification regarding message size and transport protocol selection. RFC3261 states that requests within 200 bytes of the path MTU MUST be sent using a reliable transport protocol (eg. TCP). However, it also states that if an element sends a request over TCP because of these message size constraints, and the request would have otherwise been sent over UDP, if a transport error is detected, the element SHOULD retry the request, using UDP. Does the above requirements imply that you (in the worst case) have to go through the DNS procedures of RFC3263 twice for one request? Assume you want to send a request to a URI where the domain part is not an IP-address and the port number is not present. I can come up with at least three ways of approaching this: 1. Select TCP transport based on message size and do a SRV query (_sip._tcp.domain) If a transport error is detected (or transaction timeout occurs), for all the candiates resolved, start from scratch with a NAPTR (or perhaps an UDP SRV) query. 2. Start with a NAPTR query (as you would have done for a smaller message) and exclude resource records representing unreliable transports (UDP) from the answer when selecting a transport protocol. Then, if a transport error is detected (or transaction timeout occurs) for all the candiates resolved, start from scratch with a NAPTR query (and include all supported resource records in the answer when selecting transport protocol) Or perhaps exclude the reliable transport that just failed. Or maybe do an UDP SRV query... 3. Follow the procedure of RFC3263 as normal, and switch the transport protocol to TCP, if UDP was resolved, just before sending the request. If this request fails, switch back to UDP and use the resource records already resolved for redundancy. I guess approach #3 is somewhat mentioned implicitly in RFC3261 in that the server must listen on the same ports/interfaces for TCP as for UDP. The question is; is approach #3 the one to be recommended? If the transport URI parameter suggests UDP (for a large message), I guess the proper solution is just to override this? Regards, Richard _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 15 04:20:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJS9L-0002sH-EG; Wed, 15 Mar 2006 04:18:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJS9J-0002kU-F5 for sip@ietf.org; Wed, 15 Mar 2006 04:18:33 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJS9I-0002BL-2j for sip@ietf.org; Wed, 15 Mar 2006 04:18:33 -0500 Received: by tutpro.com (Postfix, from userid 65534) id E3A251403F8; Wed, 15 Mar 2006 11:18:30 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 7916D1403EF; Wed, 15 Mar 2006 11:18:20 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 105ECF027F; Wed, 15 Mar 2006 11:18:47 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17431.56311.6512.850916@rautu.tutpro.com> Date: Wed, 15 Mar 2006 11:18:47 +0200 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B55@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1B55@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, pkyzivat@cisco.com, dean.willis@softarmor.com, princeap@gmail.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 Christer Holmberg (JO/LMF) writes: > A simple use-case, not necessarily related only to 3G, is when one wants > only to use a single codec. The UAC then send his lists of codecs, gets > back the UAS list of codecs, and then send a new offer with only one > codec both supports. this is theoretical, since many existing SIP implementations don't return a list of codecs, but only one, so there would be nothing else for the UAC to choose from. if UAS would return many, why can't the UAC send a re-invite after ACK? > Another use-case is where the first offer indicates "inactive", e.g. > because of radio bearer and/or other resource reasons, and then want to > be able to change that to "sendrecv" before 200 OK. i don't understand the example, but again, why can't re-invite be used? why i'm pissed off because of PRACK is that now some non-3gpp SIP UAs have tried to implement it and most of them have done it somehow wrong. customers who buy these phones then complain to me about it. if SIP UA vendors can't get it right, the feature is clearly too complicated and must be deprecated. -- 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 Mar 15 04:30:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSJT-0006hd-2G; Wed, 15 Mar 2006 04:29:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSJR-0006hN-7W for sip@ietf.org; Wed, 15 Mar 2006 04:29:01 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJSJP-0002IX-PE for sip@ietf.org; Wed, 15 Mar 2006 04:29:01 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2F9R0S8020900; Wed, 15 Mar 2006 11:27:01 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 11:28:56 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 11:28: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 11:28:56 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0212EF6E@esebe103.NOE.Nokia.com> In-Reply-To: <17431.54913.828994.533928@rautu.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIDjjQHuU5F0FYQ/+lsaF2GafeMwAAfZZA From: To: X-OriginalArrivalTime: 15 Mar 2006 09:28:56.0179 (UTC) FILETIME=[E1D08C30:01C64812] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.com, christer.holmberg@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 Hi, I do not agree it would be great to make sure that the mobile SIP applications would never be able to interoperate with those applications running in desktop PCs.=20 I see signs towards other kind of direction (fixed IP network operators planning to provide access towards 3G IMS, some PC vendors planning to add SIM card support to laptops etc.) So that is why I hope solutions could be found that satisfy the needs of Internet as a whole, including the way how 3G networks are aiming to provide the access to it. In 3GPP they have tried to do their specifications so that the applications would be compliant to Internet world based on IETF specifications, so that e.g. multimedia sharing would be possible between a mobile phone and a PC. Preconditions is one of the few specs created within IETF that 3GPP has originally mandated due to radio access specific reasons, but they have relaxed this requirement to be a preferred option. Anyway since offer/answer and preconditions is one of the cornerstones in 3GPP specifications, any backwards incompatible changes for those specs will have a major impact to that community. In my opinion this is one of the views (amongst many other important ones) worth considering in this discussion. Regards, Erkki=20 >-----Original Message----- >From: ext Juha Heinanen [mailto:jh@tutpro.com]=20 >Sent: 15.March.2006 10:55 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: christer.holmberg@ericsson.com; pkyzivat@cisco.com;=20 >princeap@gmail.com; sip@ietf.org >Subject: RE: [Sip] The Problem with PRACK > >Erkki.Koivusalo@nokia.com writes: > > > I agree with you. But this far it has been possible and > > there are implementations using that option, for specific > > reasons. I did not intend to tell more than that and still > > think it was relevant input for this discussion. > >my suggestion is that PRACK is deprecated and if mobile vendors still >need it, they can solve the problems on 3gpp mailing lists. > >-- 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 Mar 15 04:43:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSVs-00066U-C0; Wed, 15 Mar 2006 04:41:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSVq-00063X-J0 for sip@ietf.org; Wed, 15 Mar 2006 04:41:50 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJSVq-0002UK-3P for sip@ietf.org; Wed, 15 Mar 2006 04:41:50 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2F9fkKj001845; Wed, 15 Mar 2006 11:41:46 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 11:41:46 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 11:41: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 11:41:43 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0212EF8B@esebe103.NOE.Nokia.com> In-Reply-To: <17431.54702.803803.907459@rautu.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIDcfNmeki2xsWSEm6sfHXbyiEdwABVE9w From: To: , , , , X-OriginalArrivalTime: 15 Mar 2006 09:41:45.0911 (UTC) FILETIME=[AC9C5470:01C64814] X-Spam-Score: 0.2 (/) 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 Hi, One reason might be that the 3G SIP proxy would be located to the home network of the user in Germany while the user is travelling to Venzuela and using the local 3G access network. The proxy does not have any control to the remote access. SIP proxies are in general not related to access networks and in my opinion it would not be so good idea to try tying them together like that. Internet approach has been to keep most of the intelligence in terminals and the networks to provide services as the terminals request them. I know that in 3G the spec is not always like that, but the less that kind of dependencies there are the better. Regards, Erkki=20 >-----Original Message----- >From: ext Juha Heinanen [mailto:jh@tutpro.com]=20 >Sent: 15.March.2006 10:52 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); sip@ietf.org;=20 >pkyzivat@cisco.com; princeap@gmail.com; dean.willis@softarmor.com >Subject: RE: [Sip] The Problem with PRACK > >Juha Heinanen writes: > > > still don't get it. why can't the 3g proxy allocate=20 >bandwidth for the > > highest bandwidth codec in the invite? > >... and then possibly reduce the allocation when 200 OK comes back or >remove the allocation completely if something else comes back. > >-- 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 Mar 15 04:45:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSXv-0007bs-6z; Wed, 15 Mar 2006 04:43:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSXu-0007bi-8J for sip@ietf.org; Wed, 15 Mar 2006 04:43:58 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJSXt-0002Wm-HU for sip@ietf.org; Wed, 15 Mar 2006 04:43:58 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B79A561F; Wed, 15 Mar 2006 10:43:56 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 10:43:56 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 10:43:56 +0100 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] The Problem with PRACK Date: Wed, 15 Mar 2006 10:43:55 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B57@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIEXEXEy9DFwPsTpuvsc09oLbafAAAphYQ From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 15 Mar 2006 09:43:56.0367 (UTC) FILETIME=[FA5E55F0:01C64814] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org, pkyzivat@cisco.com, dean.willis@softarmor.com, princeap@gmail.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,=20 >A simple use-case, not necessarily related only to 3G, is when one wants only to use a single codec. The UAC then send=20 >his lists of codecs, gets back the UAS list of codecs, and then send a new offer with only one codec both supports. this is theoretical, since many existing SIP implementations don't return a list of codecs, but only one, so there would be nothing else for the UAC to choose from. [CHH] I am not sure I agree on that. But, in any case I don't like making standards based on assumptions... >if UAS would return many, why can't the UAC send a re-invite after ACK? [CHH] One may want to do this before the call has been established. Also, in forking scenarios an "early" answer COULD even trigger termination of certain early dialogs. >Another use-case is where the first offer indicates "inactive", e.g. >because of radio bearer and/or other resource reasons, and then want to >be able to change that to "sendrecv" before 200 OK. i don't understand the example, but again, why can't re-invite be used? [CHH] Again, one may want to do this before the call has been established. There may even be regulatory issues related to this - I don't know... >why i'm pissed off because of PRACK is that now some non-3gpp SIP UAs have tried to implement it and most of them have=20 >done it somehow wrong. >customers who buy these phones then complain to me about it. if SIP UA vendors can't get it right, the feature is=20 >clearly too complicated and must be deprecated. [CHH] I think we have two issues here. 1) Shall one be able to send new offer(s) before 200 OK? That can already be done using UPDATE. 2) Shall it be possible to use PRACK for sending offer or answer. My understanding is that the scope of this discussion is the second issue, so maybe we should focus on that? Regards, Christer -- 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 Mar 15 04:53:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSfj-0003Hi-79; Wed, 15 Mar 2006 04:52:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSfh-0003Hd-Tt for sip@ietf.org; Wed, 15 Mar 2006 04:52:01 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJSfg-0002fE-Iv for sip@ietf.org; Wed, 15 Mar 2006 04:52:01 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 5E09E1403F8; Wed, 15 Mar 2006 11:51:59 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 026041403EF; Wed, 15 Mar 2006 11:51:49 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id B4806F027F; Wed, 15 Mar 2006 11:52:10 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17431.58314.683040.709065@rautu.tutpro.com> Date: Wed, 15 Mar 2006 11:52:10 +0200 From: Juha Heinanen To: Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0212EF8B@esebe103.NOE.Nokia.com> References: <17431.54702.803803.907459@rautu.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F0212EF8B@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.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 Erkki.Koivusalo@nokia.com writes: > One reason might be that the 3G SIP proxy would be located to > the home network of the user in Germany while the user is > travelling to Venzuela and using the local 3G access network. > The proxy does not have any control to the remote access. fine, i don't like the proxy approach either. if SIP UA does the allocation, it can follow the same procedure: allocate first for the highest it can support and reallocate if less comes back. -- 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 Mar 15 04:57:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSiy-0005FR-1u; Wed, 15 Mar 2006 04:55:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSix-0005FL-HL for sip@ietf.org; Wed, 15 Mar 2006 04:55:23 -0500 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJSiw-0002mj-3o for sip@ietf.org; Wed, 15 Mar 2006 04:55:23 -0500 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k2F9tKln004266 for ; Wed, 15 Mar 2006 10:55:20 +0100 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id k2F9tJsY019280 for ; Wed, 15 Mar 2006 10:55:20 +0100 Message-ID: <4417E48E.5050204@alcatel.fr> Date: Wed, 15 Mar 2006 10:55:26 +0100 From: Thomas Froment Organization: Alcatel User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] Selecting a Transport Protocol References: <4417DAB2.30201@owera.com> In-Reply-To: <4417DAB2.30201@owera.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: sip@ietf.org X-Mailman-Version: 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 inline... Richard Aas wrote: > Hi all, > > I need some clarification regarding message size and transport > protocol selection. > > 3. Follow the procedure of RFC3263 as normal, and switch the transport > protocol > to TCP, if UDP was resolved, just before sending the request. If > this request > fails, switch back to UDP and use the resource records already > resolved for > redundancy. > > I guess approach #3 is somewhat mentioned implicitly in RFC3261 in > that the > server must listen on the same ports/interfaces for TCP as for UDP. The > question is; is approach #3 the one to be recommended? In my opinion, this is the right one, no need to make RFC 3263 resolution twice. the 3261, section 18.1.1 on path MTU just "overrides" the resolved transport for the specific case of messages having size > MTU size-200... > > If the transport URI parameter suggests UDP (for a large message), I > guess > the proper solution is just to override this? It seems yes, at first I found it somewhat surprising since it means a request URI with explicit transport=UDP parameter, can still lead to send a request in TCP, but it appears to be the correct behavior... 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 Wed Mar 15 04:59:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSkm-0006UN-2L; Wed, 15 Mar 2006 04:57:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSkk-0006UI-Tb for sip@ietf.org; Wed, 15 Mar 2006 04:57:14 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJSkj-0002sP-HP for sip@ietf.org; Wed, 15 Mar 2006 04:57:14 -0500 Received: by tutpro.com (Postfix, from userid 65534) id D252F140400; Wed, 15 Mar 2006 11:57:12 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 61D9A1403EF; Wed, 15 Mar 2006 11:57:02 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 952F3F027F; Wed, 15 Mar 2006 11:57:29 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17431.58633.549533.532257@rautu.tutpro.com> Date: Wed, 15 Mar 2006 11:57:29 +0200 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B57@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1B57@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, pkyzivat@cisco.com, dean.willis@softarmor.com, princeap@gmail.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 Christer Holmberg (JO/LMF) writes: > [CHH] I am not sure I agree on that. But, in any case I don't like > making standards based on assumptions... there was no assumptions, just facts regarding current SIP phone implementations. > >if UAS would return many, why can't the UAC send a re-invite after ACK? > [CHH] One may want to do this before the call has been established. yes and this "wanting" has resulted in PRACK that nobody seems to be able to implement in an interoperable way. > Also, in forking scenarios an "early" answer COULD even trigger > termination of certain early dialogs. i don't understand what you mean by "early" answer. a proxy that does forking, answers when it has got all replies from the forks. > [CHH] Again, one may want to do this before the call has been > established. There may even be regulatory issues related to this - I > don't know... your "may want" is very vague. i would not standardize anything beased on that kind of requirement. > 2) Shall it be possible to use PRACK for sending offer or answer. > > My understanding is that the scope of this discussion is the second > issue, so maybe we should focus on that? yes, and my solution is to deprecate PRACK and we are done with the problem. -- 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 Mar 15 09:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJWaY-0000oR-0E; Wed, 15 Mar 2006 09:02:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJWaX-0000oM-2Y for sip@ietf.org; Wed, 15 Mar 2006 09:02:57 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJWaV-0001z3-Qo for sip@ietf.org; Wed, 15 Mar 2006 09:02:57 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2006 06:02:56 -0800 X-IronPort-AV: i="4.02,194,1139212800"; d="scan'208"; a="262048346:sNHT31572320" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2FE2qYg021804; Wed, 15 Mar 2006 06:02:52 -0800 (PST) Received: from [216.102.208.11] (sjc-vpn7-590.cisco.com [10.21.146.78]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2FE4Evn002172; Wed, 15 Mar 2006 06:04:15 -0800 Message-ID: <44181E84.8070009@cisco.com> Date: Wed, 15 Mar 2006 06:02:44 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=882; t=1142431456; x=1142863656; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20SBCs=20and=20draft-ietf-sip-identity-06 |To:Cullen=20Jennings=20; X=v=3Dmtcc.com=3B=20h=3DPnqc/1KBH90PIZohihQvGOxjvr4=3D; b=eUz5UqShcFRhkB7SuN6EZuqRonAaDmDP2CXgV19N00if52l637RKOeFQqooNr+vLelMV+2Dh DJy+h2LLsvMsQ3K362f3IHm6abcLFjMpuUYMJ2BOENcULVXSXHHfoJTs+R+Ohpb5Ooe1MlEVP5d mfgy0+dN/4epQzn4z8xJWV6A=; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "sip@ietf.org" , Hans Persson , 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 Cullen Jennings wrote: > So call in domain A goes to B2BUA in domain B. B2BUA checks the identity and > if it is not good, it discards the call. If it likes it the identity, it > maps to a name in domain B, signs with credential in domain B, and sends to > client in domain B that is trusts credentials in domain B. You are right > that the B2BUA need to check the identity for you but that is the nature of > anything that changes Identity items. It's not much differnt than the > outgoing direction. What is this mapping function, and what is a UAS supposed to do with the mapped identity? And this seems to assume that the B2BUA is always in the same adminstrative domain as the UAS, which is not always the case, and even if it is it may not be trustworthy. This smells suspiciously like the mailing list problem in DKIM, and details matter. A lot. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 15 09:20:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJWpz-0007mg-Il; Wed, 15 Mar 2006 09:18:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJWpy-0007mY-HW for sip@ietf.org; Wed, 15 Mar 2006 09:18:54 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJWpw-0002nr-R1 for sip@ietf.org; Wed, 15 Mar 2006 09:18:54 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9DE08C81; Wed, 15 Mar 2006 15:18:51 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 15:18:51 +0100 Received: from [136.225.183.102] ([136.225.183.102]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 15:18:47 +0100 From: "Christer Holmberg" To: "Juha Heinanen" Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 16:13:50 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 15 Mar 2006 14:18:50.0631 (UTC) FILETIME=[61B74970:01C6483B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, pkyzivat@cisco.com, dean.willis@softarmor.com, princeap@gmail.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I don't want to make assumptions based on how current implementations may = work.=20 With "early answer" I meant an answer received in a reliable 18x. And, a = forking proxy WILL forward ALL of those. Also, I don't know in what environment you are using your SIP phones, but = obvously you don't have to consider the same resource issues as others must = do. But, I agree with you that using PRACK for offer/answer causes issues, but = I wouldn't "blame" it on the fact that people want to do multiple = offer/answer transactions before 200 OK. I still think the are two separate = issues... 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 Mar 15 09:44:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXD7-0005MR-Q8; Wed, 15 Mar 2006 09:42:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXD7-0005MM-0r for sip@ietf.org; Wed, 15 Mar 2006 09:42:49 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJXD6-0003Ek-IV for sip@ietf.org; Wed, 15 Mar 2006 09:42:49 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2006 06:42:48 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,194,1139212800"; d="scan'208"; a="23642035:sNHT28597856" 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 k2FEgiWg026440; Wed, 15 Mar 2006 09:42:47 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 09:42:44 -0500 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] The Problem with PRACK Date: Wed, 15 Mar 2006 09:42:22 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30137C8A8@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHOHchwiZepEnEQKyOIw4lVBiYVQATjQNAAC2+QQA= From: "Michael Hammer \(mhammer\)" To: "Brian Stucker" , "Dean Willis" , "Cullen Jennings \(fluffy\)" X-OriginalArrivalTime: 15 Mar 2006 14:42:44.0694 (UTC) FILETIME=[B87BEF60:01C6483E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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: Brian Stucker [mailto:bstucker@nortel.com]=20 > Sent: Tuesday, March 14, 2006 11:55 AM > To: Dean Willis; Cullen Jennings (fluffy) > Cc: sip@ietf.org; Francois Audet; Paul Kyzivat (pkyzivat) > Subject: RE: [Sip] The Problem with PRACK >=20 > Based on your proposals below, cryptographically transparent=20 > versus redirection: >=20 > How would you go about addressing applications like CPL that=20 > need to run timers for service logic and thus need to have=20 > some level of control over the session (not necessarily=20 > what's in the body of the messages, just where they're going)=20 > if a redirection model is used? >=20 > For example, without mucking about with what's inside the=20 > request, triggering off of the request URI of an INVITE to=20 > forward to destination A for X seconds and then to=20 > destination B. In this example the next hop changes over time=20 > for the same request and does not seem possible using=20 > redirection. This seems to preclude redirection as a general=20 > solution and drive towards requiring a proxy to be=20 > cryptographically transparent. Is there a reason the redirect server couldn't send you to A,=20 which then redirects or Refers you to B when A is done with=20 it's part of the service? It seems the proxy is best at directing traffic, while the UAS could contain distributed feature logic. Think of an assembly line of robots, each which knows its part of the process, but=20 not necessarily the whole. Mike >=20 > If the proxy is transparent, then how do you go about not=20 > precluding deep-packet inspection issues raised by=20 > applications such as QoS enforcement, network enforced=20 > identity or other services? It seems to me that HTTPS may=20 > make a bad model in that I'm unaware of any HTTPS-based=20 > application that has a box in the middle that needs to=20 > inspect and enforce certain characteristics of the request=20 > before it is handled by the final consumer of that request. >=20 > This seems to preclude cryptographic transparency as a=20 > general solution.=20 >=20 > I'm sure either can be used effectively in many application=20 > spaces, but it does not seem that either can be used as a=20 > general solution in the protocol itself. >=20 > Regards, > Brian >=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, March 14, 2006 1:08 AM > To: Cullen Jennings > Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul H Kyzivat > Subject: Re: [Sip] The Problem with PRACK >=20 >=20 >=20 > On Mar 14, 2006, at 12:24 AM, Cullen Jennings wrote: >=20 > > On 3/13/06 10:27 AM, "Dean Willis"=20 > wrote: > > > >> Right. But, SIPS is only required as far as the proxy serving the=20 > >> AOR. The AOR to Contact vector could be UDP/IPSEC, or even=20 > just plain=20 > >> unsecured UDP. > > > > I think we have a gathering amount of evidence that we want=20 > to update=20 > > this regardless of UDP or PRACK. >=20 >=20 > It's true that SIP proxies just don't work "right" with SIPS as it is. >=20 > When people first look at the "SIPS is only valid to the=20 > serving proxy" model they assume that simply changing the=20 > requirement to say that the proxy-to-UA leg must also be SIPS=20 > protected would provide a satisfactory answer. It doesn't,=20 > and this requires some careful thinking. >=20 > What security do you mandate on the serving-proxy to UA link? TLS? =20 > TLS supports many different ciphersuites. What keeps the=20 > crypto on the SP-UA link from being watered-down? Would other=20 > protections like IPSEC suffice? How would you end-to-end=20 > negotiate the cryptography so that the originating UA could=20 > believe that the entire chain was protected to some minimal=20 > level? And how do you offer some level of security to an IMS=20 > fashion-victim who is always going to be exposed to MITM=20 > attacks from his own service provider by design? >=20 > Personally, I think the only way SIPS really gives us the=20 > level of protection we have come to expect from HTTPS is if=20 > it is used end-to- end, either by abandoning proxy-routing in=20 > favor of a redirect model, or by causing the proxies to be=20 > cryptographically transparent as is done with HTTPS proxies. >=20 > This is an important thing to note: HTTPS proxies do NOT "see=20 > inside" =20 > the HTTPS stream. All they do is pass it along, unchanged, to=20 > the next hop. It could actually be some other protocol than=20 > HTTP, and they don't care and can't tell. To-date, we haven't=20 > treated SIPS proxies that way, and instead presume they have=20 > access to the full stream, in many cases "write access" so=20 > that they can munge various header fields about. >=20 > -- > Dean >=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=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 Mar 15 11:45:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZ65-00009G-TV; Wed, 15 Mar 2006 11:43:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZ4z-0008DS-Is for sip@ietf.org; Wed, 15 Mar 2006 11:42:33 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJYsY-00074E-KL for sip@ietf.org; Wed, 15 Mar 2006 11:29:43 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJYsW-000MRB-53; Wed, 15 Mar 2006 16:29:40 +0000 To: "Romascanu, Dan \(Dan\)" , j.schoenwaelder@iu-bremen.de Date: Wed, 15 Mar 2006 08:29:40 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: fluffy@cisco.com, sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com, bwijnen@lucent.com Subject: [Sip] Update of SIP MIB to your MIB Doctor comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Message-Id: Hi, Dan, Juergen, The recently released draft-ietf-sip-mib-10 is an update responding to the MIB Doctor comments. Because the cycling on this draft is very long, and Dan's time is going to be very tight (congratulations on the ADship - ulp) I'm hoping you could re-review this quickly. If you have any issues but they are not too big, I'd like to advise Cullen to send the document to IETF Last Call with your concerns as Last Call comments. Depending of course on the needed fixes, a revision or Notes to the RFC Editor could even be possible after the IESG review. Bottom line: re-review? Allison A reminder of your review: > > Here are my review comments. I apologize for the delay, but > unfortunately the document is not yet completely problems free, and it > generated some discussions 'in the doctors room': > > A few issues were found related to the definition of the > SipMethodIdentifier TC and its usage: > > 1. The way it is defined the TC encourages extensibility, and this can > be regarded as a good thing. In order to do this a vendor must invent > some numerical assignment, which is not yet used by the standard, and > the DESCRIPTION requires that this assignment "MUST ensure no collision > with officially assigned method identifier values" but says nothing > about how collision can be avoided. It would be useful to split the > identifiers numbers space into standard and experimental, and create a > second experimental registry where vendors building an extension method > and receive a number in the experimental space. This would ensure that > collisions are avoided, and experimental methods are identified at a > glance. > 2. Another MIB Doctor asked 'why the method name has not been used as an > index as this would be the natural naming scheme. Having to go through a > lookup table (in case the SipMethodIdentifier has only local > significance) is painful and the alternative to establish another IANA > registry to number the SIP methods seems also kind of costly.'. I am not > sure that a change is necessary at this stage, as nothing is broken, but > as I would suggest that you provide a rationale for this design choice. > 3. The TC misses a DISPLAY-HINT (probably "d"), which results into a > smilint warning > > Some more editorial things. > > 4. Since the document was published the Intellectual Property > boilerplates were updated. See > http://www.ietf.org/ietf/1id-guidelines.txt for the latest version > 5. It is recommended that the module name of the SIP-TC module be > changed to SIP-TC-MIB > 6. typo - DESCRIPTION clause of SipStatusCodeNotifTable - "seperate" > 7. typo - DESCRIPTION clause of SipMethodIdentifier - "extention" > 8. typo - DESCRIPTION clause of sipServiceNotifEnable - "approriate" > 9. type - DESCRIPTION clause of sipServiceWarmStart - "adminstrative" > 10. There are 129 instances of too long lines in this documents. Please > run idnits for the full list > http://ietf.levkowetz.com/tools/idnits/idnits.pyht > 11. Warnings of weird spacing in lines > tmp/draft-ietf-sip-mib-09.txt(4495): Line has weird spacing: '...CodeIns > rena...' > tmp/draft-ietf-sip-mib-09.txt(4496): Line has weird spacing: '...odeOuts > renam...' > tmp/draft-ietf-sip-mib-09.txt(4789): Line has weird spacing: '...odTable > in th...' > 12. As Section 8 including the Log of Changes will be taken out, but > there are other sections after this section it would be better to move > it to an annex and renumber, making sure that proper references from the > text go to the intended place. > > Regards, > > Dan > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 15 12:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZlq-0005TN-3R; Wed, 15 Mar 2006 12:26:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZlo-0005TI-4b for sip@ietf.org; Wed, 15 Mar 2006 12:26:48 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJZlm-0000GY-Sz for sip@ietf.org; Wed, 15 Mar 2006 12:26:48 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k2FHQeLJ095715; Wed, 15 Mar 2006 12:26:44 -0500 (EST) From: "Brett Tate" To: "'Christer Holmberg \(JO/LMF\)'" , "'Paul Kyzivat'" Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 12:27:45 -0500 Message-ID: <001f01c64855$c634b1c0$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B54@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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'm not sure I see a real problem here. An offer in a prack can't be=20 > the first offer. As a subsequent offer, it is constrained it what it=20 > can contain in such a way that the answer should always be able to=20 > achieve something tolerable, if not desirable. >=20 > [CHH] In theory, the offer could contain one or more new streams. But, = > there can also be a technical reason why the receiver simply isn't=20 > capable of processing the offer at the time it is received. >=20 > In any case, I don't a solution where one isn't able to reject an=20 > offer > - for whatever reason... I agree; the UAS should be able to reject the PRACK's offer. The = solution presented within draft-sawada-sipping-sip-offeranswer is to answer the = offer and trigger an immediate UPDATE to try to change things again. = Returning responses like 488, 606, 504, etcetera seem more appropriate. Unfortunately, rfc3262 and rfc3311 did not clearly identify a failure response to send when the UAS cannot accept a PRACK/UPDATE with an offer/answer SDP. This has led to interoperability problems with = devices desiring benefits of UPDATE and PRACK; but don't desire/support them containing an SDP. The 504 response mentioned within rfc3311 helps for UPDATE if devices actually support receiving without releasing the call; however it = definitely isn't a perfect solution. =20 Returning a 200 response without an SDP to PRACK offer is not a perfect solution and is currently considered non compliant. However it is = commonly observed when interworking with devices which implemented (deployed) = draft versions of 100rel functionality and are unable/unwilling to disable = 100rel usage. And because it isn't explicitly mentioned within the rfc3262, = many devices currently do not expect to receive a 504 as discussed within rfc3311. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 15 14:31:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbg9-00068O-5K; Wed, 15 Mar 2006 14:29:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbg8-00068J-Ei for sip@ietf.org; Wed, 15 Mar 2006 14:29:04 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbg7-0004Un-70; Wed, 15 Mar 2006 14:29:04 -0500 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 15 Mar 2006 11:29:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,195,1139212800"; d="scan'208"; a="533928491:sNHT20854752" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 11:29:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Mar 2006 11:25:13 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Latest draft for SDP extensions in SIP IM Thread-Index: AcZIZi61fBe1U24QQja3ZB+QXfordQ== From: "Anil Bollineni" To: , X-OriginalArrivalTime: 15 Mar 2006 19:29:02.0272 (UTC) FILETIME=[B71E5400:01C64866] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Sip] Latest draft for SDP extensions in SIP IM X-BeenThere: sip@ietf.org X-Mailman-Version: 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 want to know what is latest draft/rfc for indicating SDP extensions in = SIP IM call flows. I foudn this draft draft-ietf-simple-im-sdp-00, but = it is old. =20 Thanks in Advance, -Anil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 15 14:51:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbzm-0007sD-M9; Wed, 15 Mar 2006 14:49:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbzl-0007s5-8E; Wed, 15 Mar 2006 14:49:21 -0500 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbzj-0004nj-RA; Wed, 15 Mar 2006 14:49:21 -0500 Content-class: urn:content-classes:message Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering MIME-Version: 1.0 Date: Wed, 15 Mar 2006 21:49:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550F40A0@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering Thread-Index: AcY7ZN3cwRh/qe6jRae0/Pqfce73PgNAvLFY References: <28F05913385EAC43AF019413F674A0170DE0C2DF@OCCLUST04EVS1.ugd.att.com> <3B5E51BE-ACE2-40BA-9DE3-6427D91B9116@softarmor.com> From: "David Schwartz" To: "Dean Willis" X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, Sipping List , Jon Peterson X-BeenThere: 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="===============2087101119==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2087101119== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64869.8BD0D7D5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64869.8BD0D7D5 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Guys. =20 While thinking of ways to lessen the load on you guys I reread a whole = bunch of drafts and came to the realization that perhaps the correct = approach to this problem is to move some of the drafts to the SPEERMINT = WG. There are many drafts that predate SPEERMINT and now that this WG = exists these drafts should probably move to there. =20 Basically, any draft that deals with issues outside the domain = administrator should migrate over. So issues like GRUU or OUTBOUND that = deal with relationship between UA and DA stay. Issues like Traits, = Identity, SAML, SPIT etc, that in their very essence deal with the = interdomain issues should probably migrate over. =20 Any thoughts? =20 David Schwartz ------_=_NextPart_001_01C64869.8BD0D7D5 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Sipping] Re: [Sip] Thoughts on the Principle of = DividingandConquering=0A= =0A= =0A=
=0A=
Hi Guys.
=0A=
 
=0A=
While thinking of ways to lessen the load = on you guys =0A= I reread a whole bunch of drafts and came to the realization that = perhaps the =0A= correct approach to this problem is to move some of the drafts to = the  =0A= SPEERMINT WG. There are many drafts that predate SPEERMINT and now that = this WG =0A= exists these drafts should probably move to there.
=0A=
 
=0A=
Basically, any draft that deals with = issues outside =0A= the domain administrator should migrate over. So issues like GRUU or = OUTBOUND =0A= that deal with relationship between UA and DA stay. Issues like Traits, =0A= Identity, SAML, SPIT etc, that in their very essence deal with the =0A= interdomain issues should probably migrate over.
=0A=
 
=0A=
Any thoughts?
=0A=
 
=0A=
 David Schwartz
=0A= =0A= =0A= ------_=_NextPart_001_01C64869.8BD0D7D5-- --===============2087101119== 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 --===============2087101119==-- From sip-bounces@ietf.org Wed Mar 15 15:14:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJcMN-0002dp-7G; Wed, 15 Mar 2006 15:12:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJcML-0002dk-6x for sip@ietf.org; Wed, 15 Mar 2006 15:12:41 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJcMK-0005jt-Ns for sip@ietf.org; Wed, 15 Mar 2006 15:12:41 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2006 15:12:41 -0500 X-IronPort-AV: i="4.02,195,1139202000"; d="scan'208"; a="84199907:sNHT35365184" 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 k2FKCeVU016046; Wed, 15 Mar 2006 15:12:40 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 15:12:40 -0500 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] The Problem with PRACK Date: Wed, 15 Mar 2006 15:12:38 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30137CAB0@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHOHchwiZepEnEQKyOIw4lVBiYVQATjQNAAC2+QQAAAvjd0AAIkL4A From: "Michael Hammer \(mhammer\)" To: "Brian Stucker" , "Dean Willis" , "Cullen Jennings \(fluffy\)" X-OriginalArrivalTime: 15 Mar 2006 20:12:40.0011 (UTC) FILETIME=[CF6999B0:01C6486C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 302 can have multiple contacts. =20 The originator sends INVITE to the first contact,=20 and upon no answer sends to the second AoR. The thought is that the correct end result from user experience can occur,=20 maybe just no in the exact way, with exact node sequence as before,=20 with features in exactly the same place. I am just trying to escape a single switch mentality. Need to re-think all the features then. Mike =20 > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com]=20 > Sent: Wednesday, March 15, 2006 12:38 PM > To: Michael Hammer (mhammer); Dean Willis; Cullen Jennings (fluffy) > Cc: sip@ietf.org; Francois Audet; Paul Kyzivat (pkyzivat) > Subject: RE: [Sip] The Problem with PRACK >=20 > I don't know that I follow you suggestion in the specific=20 > case I am talking about. >=20 > Take for instance Call Forward No Answer. In this case, A=20 > never says that it's done with the call before it is=20 > retargeted to B by the network. A and B have no idea that the=20 > service even exists in the middle. >=20 > Regards, > Brian >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, March 15, 2006 8:42 AM > To: Stucker, Brian [RICH1:B620:EXCH]; Dean Willis; Cullen Jennings > (fluffy) > Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat > (pkyzivat) > Subject: RE: [Sip] The Problem with PRACK >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Brian Stucker [mailto:bstucker@nortel.com] > > Sent: Tuesday, March 14, 2006 11:55 AM > > To: Dean Willis; Cullen Jennings (fluffy) > > Cc: sip@ietf.org; Francois Audet; Paul Kyzivat (pkyzivat) > > Subject: RE: [Sip] The Problem with PRACK > >=20 > > Based on your proposals below, cryptographically transparent versus=20 > > redirection: > >=20 > > How would you go about addressing applications like CPL=20 > that need to=20 > > run timers for service logic and thus need to have some level of=20 > > control over the session (not necessarily what's in the body of the=20 > > messages, just where they're going) if a redirection model is used? > >=20 > > For example, without mucking about with what's inside the request,=20 > > triggering off of the request URI of an INVITE to forward to=20 > > destination A for X seconds and then to destination B. In=20 > this example=20 > > the next hop changes over time for the same request and=20 > does not seem=20 > > possible using redirection. This seems to preclude redirection as a=20 > > general solution and drive towards requiring a proxy to be=20 > > cryptographically transparent. >=20 > Is there a reason the redirect server couldn't send you to A,=20 > which then redirects or Refers you to B when A is done with=20 > it's part of the service? >=20 > It seems the proxy is best at directing traffic, while the=20 > UAS could contain distributed feature logic. Think of an=20 > assembly line of robots, each which knows its part of the=20 > process, but not necessarily the whole. >=20 > Mike >=20 > >=20 > > If the proxy is transparent, then how do you go about not=20 > precluding=20 > > deep-packet inspection issues raised by applications such as QoS=20 > > enforcement, network enforced identity or other services?=20 > It seems to=20 > > me that HTTPS may make a bad model in that I'm unaware of any=20 > > HTTPS-based application that has a box in the middle that needs to=20 > > inspect and enforce certain characteristics of the request=20 > before it=20 > > is handled by the final consumer of that request. > >=20 > > This seems to preclude cryptographic transparency as a general=20 > > solution. > >=20 > > I'm sure either can be used effectively in many application spaces,=20 > > but it does not seem that either can be used as a general=20 > solution in=20 > > the protocol itself. > >=20 > > Regards, > > Brian > >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, March 14, 2006 1:08 AM > > To: Cullen Jennings > > Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul H Kyzivat > > Subject: Re: [Sip] The Problem with PRACK > >=20 > >=20 > >=20 > > On Mar 14, 2006, at 12:24 AM, Cullen Jennings wrote: > >=20 > > > On 3/13/06 10:27 AM, "Dean Willis"=20 > > wrote: > > > > > >> Right. But, SIPS is only required as far as the proxy=20 > serving the=20 > > >> AOR. The AOR to Contact vector could be UDP/IPSEC, or even > > just plain > > >> unsecured UDP. > > > > > > I think we have a gathering amount of evidence that we want > > to update > > > this regardless of UDP or PRACK. > >=20 > >=20 > > It's true that SIP proxies just don't work "right" with=20 > SIPS as it is. > >=20 > > When people first look at the "SIPS is only valid to the serving=20 > > proxy" model they assume that simply changing the=20 > requirement to say=20 > > that the proxy-to-UA leg must also be SIPS protected would=20 > provide a=20 > > satisfactory answer. It doesn't, and this requires some careful=20 > > thinking. > >=20 > > What security do you mandate on the serving-proxy to UA link? TLS? =20 > > TLS supports many different ciphersuites. What keeps the=20 > crypto on the=20 > > SP-UA link from being watered-down? Would other protections=20 > like IPSEC=20 > > suffice? How would you end-to-end negotiate the=20 > cryptography so that=20 > > the originating UA could believe that the entire chain was=20 > protected=20 > > to some minimal level? And how do you offer some level of=20 > security to=20 > > an IMS fashion-victim who is always going to be exposed to MITM=20 > > attacks from his own service provider by design? > >=20 > > Personally, I think the only way SIPS really gives us the level of=20 > > protection we have come to expect from HTTPS is if it is=20 > used end-to-=20 > > end, either by abandoning proxy-routing in favor of a=20 > redirect model,=20 > > or by causing the proxies to be cryptographically transparent as is=20 > > done with HTTPS proxies. > >=20 > > This is an important thing to note: HTTPS proxies do NOT=20 > "see inside" > > the HTTPS stream. All they do is pass it along, unchanged,=20 > to the next=20 > > hop. It could actually be some other protocol than HTTP, and they=20 > > don't care and can't tell. To-date, we haven't treated SIPS proxies=20 > > that way, and instead presume they have access to the full=20 > stream, in=20 > > many cases "write access" so that they can munge various=20 > header fields=20 > > about. > >=20 > > -- > > Dean > >=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=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 15 16:22:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJdQU-0001eC-5M; Wed, 15 Mar 2006 16:21:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJdQS-0001ch-9R for sip@ietf.org; Wed, 15 Mar 2006 16:21:00 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJdQQ-0008H1-9h for sip@ietf.org; Wed, 15 Mar 2006 16:21:00 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 15 Mar 2006 13:20:57 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2FLKvw1006053; Wed, 15 Mar 2006 13:20:57 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 13:20:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] The Problem with PRACK (18x queuwing) Date: Wed, 15 Mar 2006 13:20:51 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB014831B1@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK (18x queuwing) thread-index: AcZDE2S9Uw7HnI7DRM2AObg6DmaTWQAGpO1QAQ48HDAAQ7bTAA== From: "Arunachalam Venkatraman \(arunvenk\)" To: "Christer Holmberg \(JO/LMF\)" X-OriginalArrivalTime: 15 Mar 2006 21:20:57.0389 (UTC) FILETIME=[59A3DDD0:01C64876] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 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="===============0483615081==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0483615081== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64876.596D6EBB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64876.596D6EBB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My point is that without queuing the provisionals, there is a risk of losing some of the PRACKs. =20 Suppose 18x with Rseq 2 and Rseq 3 are sent serially. If the PRACK for Rseq 2 were lost for some reason and the PRACK for Rseq 3 were received first, then a subsequent receipt of a retransmitted PRACK with Rseq 2 will be rejected by the protocol stack due to CSeq error, by sending a 500 response. Now, the retransmissions of the 18x with Rseq 2 will continue with no hope of matching up with its PRACK. ________________________________ From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, March 14, 2006 6:59 AM To: Arunachalam Venkatraman (arunvenk); Rohan Mahy; Jonathan Rosenberg (jdrosen) Cc: IETF SIP List Subject: RE: [Sip] The Problem with PRACK =20 Hi, =20 A long time ago, I proposed a solution which would not require the queueing: the INVITE request would contain the RSeq value that the UAS MUST use for the FIRST reliable provisional response. =20 Regards, =20 Christer =20 ________________________________ From: Arunachalam Venkatraman (arunvenk) [mailto:arunvenk@cisco.com]=20 Sent: 9. maaliskuuta 2006 6:06 To: Rohan Mahy; Jonathan Rosenberg (jdrosen) Cc: IETF SIP List Subject: RE: [Sip] The Problem with PRACK Regarding 1 below about having to queue up provisionals pending PRACK for first one, an additional nuance is that it is also required to queue up provisionals even after the first is PRACKed and send them one at a time, as the PRACK for each is received. If this were not done, then the PRACKS may be received out of sequence and mess up the CSeq check for requests received at the UAS. Then the UAS will futilely continue to retransmit the provisionals with no hope of ever matching the PRACKS that were returned a 500 response due to out-of-sequence receipt. ________________________________ From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 Sent: Wednesday, March 08, 2006 5:51 PM To: Jonathan Rosenberg (jdrosen) Cc: IETF SIP List Subject: Re: [Sip] The Problem with PRACK Hi, A things about PRACK come immediately to mind that are a pain to implement: 1) The UAS has to queue provisionals until it receives a PRACK for the first provisional. This is due to RSeq starting at an arbitrary value instead of just starting at 1. This is probably the simplest to fix, by just requiring the UAC to always start with a RSeq of 1.=20 2) Multiple unacknowledged provisionals can be in flight at the same time. We could potentially eliminate this requirement by acknowledging the current status instead of the whole history. In other words, when the UAS sends a new reliable provisional, it decides which (if any) of the previously sent provisionals are still relevant and sends all of them (as sipfrags or something) as a single reliable request.=20 3) If you "answer" and want to deliver a 200 OK, you have to queue it and wait if you are waiting for a PRACK to an offer or answer. Keeping track of when you can send the 200 would be easier if we did something like I recommend in #2. =20 4) Even for an acknowledged provisional, you still have to retransmit approximately every minute (I forget exactly) to prevent old proxies from deleting state for your transaction. This is one of those minor annoyances that is *almost* operationally irrelevant, and unlikely to not get coded. My proposal for simplification is to retransmit the latest reliable provisional in exactly the same way that the UAS retransmits unreliable provisionals. Who cares if there is an extra message or two for a call with 1 minute + post-answer delay?=20 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I talked Jonathan into this, and I've been sorry I did ever since. My apologies to everyone for making a bad decision. Hope this helps. thanks, -rohan On 3/7/06, Jonathan Rosenberg wrote:=20 At the last IETF, there was a lot of discussion and argument around PRACK. The spark of this debate was the ICE specification, which had words in it requiring the usage of PRACK and UPDATE in order to work with early media. There was strong pushback from many implementors that=20 anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) that showed the state machine in his implementation resulting from PRACK, and it was not pretty. =09 So, I'd like to discuss exactly what IS the problem with PRACK? There=20 are really two pieces of state machinery in play here. One piece is the complication that PRACK introduces into the offer/answer model. With PRACK, you can now get a final answer in the 18x, and then send a new offer in UPDATE, or even in PRACK itself. Another piece is the state machinery with the retransmissions itself - correlating the PRACK with a particular reliable provisional response and causing it to stop. =09 In a chat with Flemming today, he suggested in interested remedy to our=20 PRACK dilemma. Why not revise PRACK so that you can't send an offer or answer with it; it has no impact on the set of allowed O/A exchanges defined by RFC 3261. I'm not sure if that would consequently break the preconditions mechanism, but maybe there are some kind of offer/answer limitations that would simplify things. =09 So, this is one idea. I'd like for people who have complained about PRACK implementations to speak up and indicate what exactly makes it so=20 complicated for them. =09 Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems=20 jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C64876.596D6EBB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
My point is that without queuing the = provisionals, there is=20 a risk of losing some of the PRACKs.
 
Suppose 18x with Rseq 2 and Rseq 3 = are sent=20 serially.
If the PRACK for Rseq 2 were lost for some = reason and the=20 PRACK for Rseq 3 were received first, then a subsequent receipt of a=20 retransmitted PRACK with Rseq 2 will be rejected by the protocol stack = due to=20 CSeq error, by sending a 500 response. Now, the retransmissions of the = 18x with=20 Rseq 2 will continue with no hope of matching up with its=20 PRACK.

From: Christer Holmberg (JO/LMF)=20 [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, March = 14, 2006=20 6:59 AM
To: Arunachalam Venkatraman (arunvenk); Rohan Mahy; = Jonathan=20 Rosenberg (jdrosen)
Cc: IETF SIP List
Subject: RE: = [Sip] The=20 Problem with PRACK

 
Hi,
 
A long=20 time ago, I proposed a solution which would not require the queueing: = the INVITE=20 request would contain the RSeq value that the UAS MUST use for the FIRST = reliable provisional response.
 
Regards,
 
Christer
 

From: Arunachalam Venkatraman = (arunvenk)=20 [mailto:arunvenk@cisco.com]
Sent: 9. maaliskuuta 2006=20 6:06
To: Rohan Mahy; Jonathan Rosenberg = (jdrosen)
Cc: IETF=20 SIP List
Subject: RE: [Sip] The Problem with=20 PRACK

Regarding 1 below about having to queue up = provisionals=20 pending PRACK for first one, an additional nuance is that it is also = required to=20 queue up provisionals even after the first is PRACKed and send them one = at a=20 time, as the PRACK for each is received.
If this were not done, then the PRACKS may be = received out=20 of sequence and mess up the CSeq check for requests received = at the=20 UAS.
Then the UAS will futilely continue = to retransmit the=20 provisionals with no hope of ever matching the PRACKS that were = returned a=20 500 response due to out-of-sequence receipt.

From: Rohan Mahy = [mailto:rohan.mahy@gmail.com]=20
Sent: Wednesday, March 08, 2006 5:51 PM
To: = Jonathan=20 Rosenberg (jdrosen)
Cc: IETF SIP List
Subject: Re: = [Sip] The=20 Problem with PRACK

Hi,

A things about PRACK come immediately to mind that = are a=20 pain to implement:

1) The UAS has to queue provisionals until it = receives=20 a PRACK for the first provisional.  This is due to RSeq starting at = an=20 arbitrary value instead of just starting at 1.  This is probably = the=20 simplest to fix, by just requiring the UAC to always start with a RSeq = of 1.=20

2) Multiple unacknowledged provisionals can be in flight at the = same=20 time.  We could potentially eliminate this requirement by = acknowledging the=20 current status instead of the whole history.  In other words, when = the UAS=20 sends a new reliable provisional, it decides which (if any) of the = previously=20 sent provisionals are still relevant and sends all of them (as sipfrags = or=20 something) as a single reliable request.

3) If you "answer" and = want to=20 deliver a 200 OK, you have to queue it and wait if you are waiting for a = PRACK=20 to an offer or answer. Keeping track of when you can send the 200 would = be=20 easier if we did something like I recommend in #2. 

4) Even = for an=20 acknowledged provisional, you still have to retransmit approximately = every=20 minute (I forget exactly) to prevent old proxies from deleting state for = your=20 transaction.  This is one of those minor annoyances that is = *almost*=20 operationally irrelevant, and unlikely to not get coded.  My = proposal for=20 simplification is to retransmit the latest reliable provisional in = exactly the=20 same way that the UAS retransmits unreliable provisionals.  Who = cares if=20 there is an extra message or two for a call with 1 minute + post-answer = delay?=20

5) I would deprecate the PRACK/200 (PRACK) offer/answer = exchange. =20 I talked Jonathan into this, and I've been sorry I did ever since.  = My=20 apologies to everyone for making a bad decision.

Hope this=20 helps.
thanks,
-rohan

On 3/7/06, Jonathan=20 Rosenberg <jdrosen@cisco.com>=20 wrote:=20
At=20 the last IETF, there was a lot of discussion and argument = around
PRACK. The=20 spark of this debate was the ICE specification, which had
words in = it=20 requiring the usage of PRACK and UPDATE in order to work
with early = media.=20 There was strong pushback from many implementors that
anything = requiring=20 PRACK is unacceptable. Rohan put up a slide (IIRC)
that showed the = state=20 machine in his implementation resulting from
PRACK, and it was not=20 pretty.

So, I'd like to discuss exactly what IS the problem = with PRACK?=20 There
are really two pieces of state machinery in play here. One = piece is=20 the
complication that PRACK introduces into the offer/answer model. = With
PRACK, you can now get a final answer in the 18x, and then = send a=20 new
offer in UPDATE, or even in PRACK itself. Another piece is the=20 state
machinery with the retransmissions itself - correlating the = PRACK=20 with a
particular reliable provisional response and causing it to=20 stop.

In a chat with Flemming today, he suggested in interested = remedy=20 to our
PRACK dilemma. Why not revise PRACK so that you can't send = an offer=20 or
answer with it; it has no impact on the set of allowed O/A=20 exchanges
defined by RFC 3261. I'm not sure if that would = consequently=20 break the
preconditions mechanism, but maybe there are some kind of = offer/answer
limitations that would simplify things.

So, = this is one=20 idea. I'd like for people who have complained about
PRACK = implementations=20 to speak up and indicate what exactly makes it so
complicated for=20 them.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg,=20 = Ph.D.           &n= bsp;      =20 600 Lanidex Plaza
Cisco=20 = Fellow           &= nbsp;           &n= bsp;          =20 Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com   =             &= nbsp;           &n= bsp;  FAX:  =20 (973) 952-5050
http://www.jdrosen.net  &nb= sp;           &nbs= p;         =20 PHONE: (973) 952-5000
http://www.cisco.com

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

------_=_NextPart_001_01C64876.596D6EBB-- --===============0483615081== 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 --===============0483615081==-- From sip-bounces@ietf.org Wed Mar 15 17:08:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJe8M-000365-CM; Wed, 15 Mar 2006 17:06:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJe8K-000360-Ma for sip@ietf.org; Wed, 15 Mar 2006 17:06:20 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJe8J-0000kD-Aa for sip@ietf.org; Wed, 15 Mar 2006 17:06:20 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 6649C140411; Thu, 16 Mar 2006 00:06:17 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 6C1E3140407; Thu, 16 Mar 2006 00:06:06 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 0C48DF027F; Thu, 16 Mar 2006 00:06:33 +0200 (EET) From: Juha Heinanen To: "Christer Holmberg" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 Message-Id: <20060315220633.0C48DF027F@rautu> Date: Thu, 16 Mar 2006 00:06:33 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org, pkyzivat@cisco.com, dean.willis@softarmor.com, princeap@gmail.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 Christer Holmberg writes: > With "early answer" I meant an answer received in a reliable > 18x. And, a forking proxy WILL forward ALL of those. christer, lets say your mobile UAC first receives a 180 Ringing reply with SDP from an UAS, where the only codec requires 14 Kbps of bandwidth. before UAC makes the phone ring, it reserves 14 Kbps worth of access bandwidth from the network. after that the UAC receives 200 OK from ANOTHER UAS, where the only codec requires 64 Kbps of bandwidth. UAC then tries to increase the reservation, but gets rejected by the network. how does your PRACK complexity with reliable provisional replies help here to prevent the false ringing tone? > Also, I don't know in what environment you are using your SIP phones, > but obvously you don't have to consider the same resource issues as > others must do. my simple PRACK-free solution DOES consider limited resource issue: when UAC sends an invite, it lists only codecs that fit into its access bandwidth reservation. at the UAS end, the same happens with codecs in 200 OK reply. when UAC receives 200 OK, it may be able to reduce its reservation further based on the codec selected in 200 OK. this is a very simple working solution that lets us deprecate PRACK. in theory, you may be able to do some small optimizations, but they are not worth the added complexity. -- 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 Mar 15 17:22:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJeM9-0002Fd-Hv; Wed, 15 Mar 2006 17:20:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJeM8-0002FY-Fq for sip@ietf.org; Wed, 15 Mar 2006 17:20:36 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJeM8-0001LI-3t for sip@ietf.org; Wed, 15 Mar 2006 17:20:36 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2FMKwpP024732 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 16:20:59 -0600 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710D67DA69@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710D67DA69@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4511E10C-5FE8-4E01-942E-D4F60E36BFE5@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Cryptographic transparency in proxies (was Re: [Sip] The Problem with PRACK) Date: Wed, 15 Mar 2006 16:20:29 -0600 To: Brian Stucker X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Cullen Jennings , sip@ietf.org, Francois Audet , Paul H 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 On Mar 14, 2006, at 10:54 AM, Brian Stucker wrote: > Based on your proposals below, cryptographically transparent versus > redirection: > > How would you go about addressing applications like CPL that need > to run timers for service logic and thus need to have some level of > control over the session (not necessarily what's in the body of the > messages, just where they're going) if a redirection model is used? > My personal view is that any application that is suitable for a "proxy" can work with a proxy providing cryptographic transparency. If it can't, it's a UA application, not a proxy application. For example, stateful forking (which is heavily overused) should be a UA (possibly B2BUA,) application, and that UA needs to either be the terminal node or be cryptographically visible (from an OPES perspective) to the terminal nodes. They NEED to know that it is there and is mucking with things. > For example, without mucking about with what's inside the request, > triggering off of the request URI of an INVITE to forward to > destination A for X seconds and then to destination B. In this > example the next hop changes over time for the same request and > does not seem possible using redirection. This seems to preclude > redirection as a general solution and drive towards requiring a > proxy to be cryptographically transparent. Only when you REALLY NEED that sort of application (and then you use a B2BUA that's cryptoparticipant). It would be much easier to solve this in the general case by returning something like a 302 to the requestor, where the 302 response contains an ordered contact list along with "try" timers so that the caller's node can be responsible for its own processing. One could go so far as to return an entire CPL to the caller for processing if more than sequence-and-timer information is needed. When do you REALLY NEED that sort of processing in-proxy? Only when 1) The endpoint is broken and you're doing "in-network protocol conversion", 2) you have a privacy constraint. If you have a privacy constraint, you need a cryptoparticipant service node that's also handling media relay OR you break your privacy constraint on the media channel anyhow. This is in large part why the response-identity problem is so hard to solve in general. With SIP as-is, including "proxy retargeting", we have NO bounded expectation for where a response might be coming from. Consider a model, where all nodes are either cryptotransparent, or visibly cryptoparticipant: We initially launch a request to an AOR, targeting the known service element (which we might call "proxy" even though it's here acting as a UAS) for that AOR. We find this service element using RFC 3262 resolution or perhaps a P2P overlay mechanism. We might traverse one or more cryptotransparent proxies getting there -- they just don't matter to the service. The AOR's serving element responds with a 302. We can evaluate the identity of that respondent, because WE KNOW who we were expecting to have respond (the service element we discovered earlier). We get a new target (the registered contact) in the 302. We send a new request to that target, and we can evaluate its identity when it responds, because we KNOW who we were expecting to have respond (the contact). The unbounded response-identity problem is solved. > If the proxy is transparent, then how do you go about not > precluding deep-packet inspection issues raised by applications > such as QoS enforcement, network enforced identity or other > services? It seems to me that HTTPS may make a bad model in that > I'm unaware of any HTTPS-based application that has a box in the > middle that needs to inspect and enforce certain characteristics of > the request before it is handled by the final consumer of that > request. Duh! The primary goal IS precluding deep-packet inspection attacks. Any "service" built on that sort of model is either criminally stupid or overtly oppressive. Both are counter to the spirit of the IETF, including RFCs 2804 and 3552. We should STOP DESIGNING TO THAT MODEL IN THE IETF. Services might reasonably be be cryptoparticipant, in which case they should be visible to the endpoint, which need to actively allow the involvement of those services. "Stealth attacks" are things that people attacking a system do -- they shouldn't be designed into the system. > This seems to preclude cryptographic transparency as a general > solution. Clearly we have a different priority list. Go buy a circuit switch if you want wires. Oh never mind, I think you already have some ;-) ! -- 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 Mar 15 17:26:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJeQR-00034H-Cq; Wed, 15 Mar 2006 17:25:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJeQQ-00034C-0i for sip@ietf.org; Wed, 15 Mar 2006 17:25:02 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJeQP-0001du-Mt for sip@ietf.org; Wed, 15 Mar 2006 17:25:01 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2FMPIaw024764 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 16:25:19 -0600 In-Reply-To: <17431.18912.266470.211444@rautu.tutpro.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 16:24:51 -0600 To: Juha Heinanen X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org, Brett Tate , "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 Mar 14, 2006, at 4:55 PM, Juha Heinanen wrote: > Christer Holmberg (JO/LMF) writes: > >> When 100rel is used it gives a possibility to ACCEPT an offer, and >> send >> an answer BEFORE 200 OK. > > why is it important for the UAS to accept SDP offer before > accepting or > rejecting the invite and why it is important for the UAC to be sure > that > UAS has accepted the offer before accepting or rejecting the invite? > Because people adopted the user-expectations of the PSTN as requirements (a mistake, I believe). In this model, your phone doesn't ring unless there are resources available on the net for the call leg that will exist when you answer. So the model is: 1) Locate target. 2) Establish resources. 3) Notify the user of the target. 4) Talk. Of course, this could all have been done more easily my having first done an exploratory INVITE that returned a contact, using RSVP or NSIS to establish media resources to the contact, and then sending the INVITE to the contact. But people somehow though that doing it in a different order would make the resource management easier. In general, it didn't. -- 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 Mar 15 17:28:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJeSN-0003bh-5j; Wed, 15 Mar 2006 17:27:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJeSL-0003bc-Td for sip@ietf.org; Wed, 15 Mar 2006 17:27:01 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJeSL-0001hm-Jc for sip@ietf.org; Wed, 15 Mar 2006 17:27:01 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2FMRNtH024782 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 16:27:25 -0600 In-Reply-To: <17431.19381.704016.457484@rautu.tutpro.com> References: <4416D284.3000203@lucent.com> <4416DDEB.3030009@cisco.com> <17431.19381.704016.457484@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <183DF3FB-79A4-4194-BDFE-340460B6B68A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt Date: Wed, 15 Mar 2006 16:26:57 -0600 To: Juha Heinanen X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Cullen Jennings , "sip@ietf.org" , 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 On Mar 14, 2006, at 5:03 PM, Juha Heinanen wrote: > Paul Kyzivat writes: > >> In the long run this doesn't seem good enough. >> I would like to have the option of having my home cable provider >> host my >> private domain for me. But that provider can't reasonably have a >> separate port for every domain it hosts. > > exactly. this is one of the many examples where implementations > for key > SIP specifications don't really exist today. since security seems to > rely heavily on SIP/TLS, i would suggest retiring the working group > until decent SIP/TLS implementations exits and after that resume the > work. > nah, you're just applying the wrong model. What you need is a delegation from the private domain that says the cable provider is authoritative for it, then use the cable provider's credentials in the communication. If we can eliminate the brokenness of retargeting proxies (thereby solving the unanticipated respondent problem), we're good to go. -- 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 Mar 15 17:35:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJeZ7-00059N-Os; Wed, 15 Mar 2006 17:34:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJeZ5-00059A-Nb for sip@ietf.org; Wed, 15 Mar 2006 17:33:59 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJeZ5-00024D-Cr for sip@ietf.org; Wed, 15 Mar 2006 17:33:59 -0500 Received: by tutpro.com (Postfix, from userid 65534) id BF9F7140411; Thu, 16 Mar 2006 00:33:58 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id DE603140407; Thu, 16 Mar 2006 00:33:52 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id CDA01F027F; Thu, 16 Mar 2006 00:34:20 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17432.38508.791558.810529@rautu.tutpro.com> Date: Thu, 16 Mar 2006 00:34:20 +0200 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org, Brett Tate , "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 writes: > In this model, your phone doesn't ring unless there are resources > available on the net for the call leg that will exist when you > answer. dean, as i have tried to show in my previous message, this problem can be solved without PRACK and reliable responses. also see the example in the previous message, which tries to show that you cannot do any better than what i propose, i.e., UAC has to reserve resources according to the highest bandwidth codec in its offer list before it sends out the INVITE. -- 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 Mar 15 17:38:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJeby-0001nV-Ax; Wed, 15 Mar 2006 17:36:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJebx-0001n4-AJ for sip@ietf.org; Wed, 15 Mar 2006 17:36:57 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJebw-0002Ay-W9 for sip@ietf.org; Wed, 15 Mar 2006 17:36:57 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2FMbCE0024832 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 16:37:13 -0600 In-Reply-To: <44181E84.8070009@cisco.com> References: <44181E84.8070009@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 Date: Wed, 15 Mar 2006 16:36:45 -0600 To: Michael Thomas X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Cullen Jennings , "sip@ietf.org" , Hans Persson X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 15, 2006, at 8:02 AM, Michael Thomas wrote: > Cullen Jennings wrote: >> So call in domain A goes to B2BUA in domain B. B2BUA checks the >> identity and >> if it is not good, it discards the call. If it likes it the >> identity, it >> maps to a name in domain B, signs with credential in domain B, and >> sends to >> client in domain B that is trusts credentials in domain B. You are >> right >> that the B2BUA need to check the identity for you but that is the >> nature of >> anything that changes Identity items. It's not much differnt than the >> outgoing direction. > > What is this mapping function, and what is a UAS supposed to do > with the mapped identity? And this seems to assume that the > B2BUA is always in the same adminstrative domain as the UAS, > which is not always the case, and even if it is it may not be > trustworthy. I believe it's an assertion that the call came from fluffy@cisco.com signed not by cisco.com but by ingate.com. Do you trust ingate to make this assertion? That's up the relationship you have with ingate. I trust it a lot MORE if ingate is cryptoparticipant and I've validated the message source than if it just comes in out of the blue, but I still don't trust it a whole lot. That's a large part of why B2BUA solutions have EXTREMELY LIMITED APPLICABILITY and we don't design ANYTHING around them but conferencing-like services. -- 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 Mar 15 17:41:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJeeB-0002JR-7U; Wed, 15 Mar 2006 17:39:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJee9-0002JJ-PL for sip@ietf.org; Wed, 15 Mar 2006 17:39:13 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJee9-0002Ee-FO for sip@ietf.org; Wed, 15 Mar 2006 17:39:13 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2FMdZ3v024845 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 16:39:36 -0600 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710D67E9A1@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710D67E9A1@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9875529E-1B6B-48B2-845E-7EB3DBA26981@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 16:39:09 -0600 To: Brian Stucker X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 15, 2006, at 11:38 AM, Brian Stucker wrote: > I don't know that I follow you suggestion in the specific case I am > talking about. > > Take for instance Call Forward No Answer. In this case, A never > says that it's done with the call before it is retargeted to B by > the network. A and B have no idea that the service even exists in > the middle. That's called a "badly designed service", from a security perspective. If the service can squat on the call, whats to prevent some other MITM? -- 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 Mar 15 17:46:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJejs-0003Tc-NA; Wed, 15 Mar 2006 17:45:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJejr-0003SH-GK for sip@ietf.org; Wed, 15 Mar 2006 17:45:07 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJejr-0002Ne-67 for sip@ietf.org; Wed, 15 Mar 2006 17:45:07 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2FMjRSQ024876 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 16:45:28 -0600 In-Reply-To: <17432.38508.791558.810529@rautu.tutpro.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36452F79-C1F7-4E32-9CB6-41CC698B54D2@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 16:45:00 -0600 To: Juha Heinanen X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org, Brett Tate , "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 Mar 15, 2006, at 4:34 PM, Juha Heinanen wrote: > Dean Willis writes: > >> In this model, your phone doesn't ring unless there are resources >> available on the net for the call leg that will exist when you >> answer. > > dean, > > as i have tried to show in my previous message, this problem can be > solved without PRACK and reliable responses. also see the example in > the previous message, which tries to show that you cannot do any > better > than what i propose, i.e., UAC has to reserve resources according > to the > highest bandwidth codec in its offer list before it sends out the > INVITE. No doubt you are correct, insofar as you go. However, couple this with the per-committed-flow charging mentality. If you commit a 14kbps reservation in order to answer a call, you get billed for it. The 3GPP model allows the CALLER to commit the resource reservation, so that the CALLER gets billed for it. You might be able to fake this with clever accounting, but in general its very hard to completely attribute an IP flow to a specific call unless your reservation protocol provides hooks for this, and this has been found to require some sort of request-response cycle before the commitment occurs. Could have been RSVP, but we ended up with PRACK. I don't like it, but it is what it is. -- 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 Mar 15 17:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJenV-0004cs-Hl; Wed, 15 Mar 2006 17:48:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJenT-0004cF-8E; Wed, 15 Mar 2006 17:48:51 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJenS-0002S8-UE; Wed, 15 Mar 2006 17:48:51 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2FMn7nL024912 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 16:49:08 -0600 In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A606550F40A0@isr-jlm-mail.Kayote.com> References: <28F05913385EAC43AF019413F674A0170DE0C2DF@OCCLUST04EVS1.ugd.att.com> <3B5E51BE-ACE2-40BA-9DE3-6427D91B9116@softarmor.com> <1DDB0D3CC4E7F14FAE946361C0A606550F40A0@isr-jlm-mail.Kayote.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5020CFD7-3F88-4CAA-807D-543CEA7D3CC5@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering Date: Wed, 15 Mar 2006 16:48:40 -0600 To: David Schwartz X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, Sipping List , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 15, 2006, at 1:49 PM, David Schwartz wrote: > Hi Guys. > > While thinking of ways to lessen the load on you guys I reread a > whole bunch of drafts and came to the realization that perhaps the > correct approach to this problem is to move some of the drafts to > the SPEERMINT WG. There are many drafts that predate SPEERMINT and > now that this WG exists these drafts should probably move to there. > > Basically, any draft that deals with issues outside the domain > administrator should migrate over. So issues like GRUU or OUTBOUND > that deal with relationship between UA and DA stay. Issues like > Traits, Identity, SAML, SPIT etc, that in their very essence deal > with the interdomain issues should probably migrate over. > > Any thoughts? > > David Schwartz Making left-handed suggestions? ;-) Actually, this is not a bad idea. I disagree with the dividing line you suggest in a few cases (identity, being applicable within a domain, needs to stay in SIP), but there's clearly some work that needs to go to SPEERMINT. I was talking to one of the other chairs yesterday, and we ran through the current -sip- drafts and agreed "SPEERMINT" on a number of them. -- 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 Mar 15 17:56:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJesy-0005vo-U2; Wed, 15 Mar 2006 17:54:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJesx-0005vd-Do for sip@ietf.org; Wed, 15 Mar 2006 17:54:31 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJesw-0002qT-1t for sip@ietf.org; Wed, 15 Mar 2006 17:54:31 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 0DF5F140411; Thu, 16 Mar 2006 00:54:29 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 9402B140407; Thu, 16 Mar 2006 00:54:23 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id A8B0AF027F; Thu, 16 Mar 2006 00:54:51 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17432.39739.634339.274814@rautu.tutpro.com> Date: Thu, 16 Mar 2006 00:54:51 +0200 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <36452F79-C1F7-4E32-9CB6-41CC698B54D2@softarmor.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <36452F79-C1F7-4E32-9CB6-41CC698B54D2@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, Brett Tate , "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 writes: > If you commit a 14kbps reservation in order to answer a call, you get > billed for it. The 3GPP model allows the CALLER to commit the > resource reservation, so that the CALLER gets billed for it. yes, caller commits to the reservation when it reserves its own resources and sends out invite to UAS that lists the codecs it wants to pay for at the remote end. i don't see how you could do any better with PRACK. > You might be able to fake this with clever accounting, but in general > its very hard to completely attribute an IP flow to a specific call > unless your reservation protocol provides hooks for this, and this > has been found to require some sort of request-response cycle before > the commitment occurs. Could have been RSVP, but we ended up with > PRACK. I don't like it, but it is what it is. no need to associate IP flows to call. see above. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 15 18:09:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJf5H-0004CL-V6; Wed, 15 Mar 2006 18:07:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJf5G-0004CB-Hq for sip@ietf.org; Wed, 15 Mar 2006 18:07:14 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJf5F-0003de-5i for sip@ietf.org; Wed, 15 Mar 2006 18:07:14 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 15 Mar 2006 15:07:12 -0800 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 k2FN7Cw1017769; Wed, 15 Mar 2006 15:07:12 -0800 (PST) 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.211); Wed, 15 Mar 2006 15:07:12 -0800 Received: from [10.21.97.124] ([10.21.97.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 15:07:11 -0800 Message-ID: <44189E1F.4090603@cisco.com> Date: Wed, 15 Mar 2006 18:07:11 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] The Problem with PRACK References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> In-Reply-To: <17432.38508.791558.810529@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2006 23:07:11.0943 (UTC) FILETIME=[312B9D70:01C64885] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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, You have been talking as if preconditions are only for QoS. There are now other defined uses. For instance there are security preconditions, used to ensure that both sides know the keys and are able to communicate securely before the phone rings. Do you have another way to do that too? Paul Juha Heinanen wrote: > Dean Willis writes: > > > In this model, your phone doesn't ring unless there are resources > > available on the net for the call leg that will exist when you > > answer. > > dean, > > as i have tried to show in my previous message, this problem can be > solved without PRACK and reliable responses. also see the example in > the previous message, which tries to show that you cannot do any better > than what i propose, i.e., UAC has to reserve resources according to the > highest bandwidth codec in its offer list before it sends out the > INVITE. > > -- 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 Wed Mar 15 18:15:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfBz-0000b5-KG; Wed, 15 Mar 2006 18:14:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfBy-0000b0-5s for sip@ietf.org; Wed, 15 Mar 2006 18:14:10 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJfBx-0003oV-S6 for sip@ietf.org; Wed, 15 Mar 2006 18:14:10 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2FNEVZj025096 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 17:14:32 -0600 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E0446@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E0446@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CB0498E-BFA4-4EE0-91F4-3736FF065F29@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 17:14:05 -0600 To: "Brian Stucker" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 15, 2006, at 4:45 PM, Brian Stucker wrote: > . . . > Seriously though, I don't think we can sit back and just say that > this is a badly designed service. These are real services that > exist in the real world that we all have to design and architect > for in the near term. Sure we can. I'm fed up with being constrained by telecom-oriented preconceived notions and ending up with compromised security, broken implementations, and a headache that just won't quit. We can meet the critical end-user requirements (it just works!) much more effectively by tossing out badly designed services than by tossing out much- needed principles. > Are you pushing for an RFC-2543 type revolution versus RFC-3261? Very little in the way of protocol change is needed. We will eventually need to fix the "retargeting" design error that Jonathan noted in his route-construction draft, but we believe this can be done in a backward-compatible fashion. True, this does continue the correction of request-routing design errors in RFC 2543 that started with loose-routing in RFC 3261, but it's significantly less invasive. But we do need an ARCHITECTURAL revolution. We must STOP thinking that we have a Class-5 switch controlling a bunch of call legs, and START thinking we have intelligent endpoints connected to the Internet. > We also have many esteemed colleagues in 3GPP and 3GPP2 (amongst > other groups) as you well know that allow and rely on deep packet > inspection (like the P-CSCF and S-CSCF) with all sorts of service > and routing interactions to boot. It seemed like in your earlier > reply that you were suggesting that if a SIP proxy didn't change > anything in the message other than the request URI and did it more > than once that it should be a BBUA. Did I read you correctly? Actually, I'd say that if a SIP proxy really needs to change the request URI (which is not the same as the request routing), then it needs to be a B2BUA. And that most cases where we THINK we need to change the request-URI can and should be accommodated by redirection. As for our colleagues who have consistently violated Internet design principles in their architectures -- I'm sorry they did this. I tried to warn them. Perhaps I didn't try hard enough, or simply failed to communicate, and am guilty therefore of complicity. So hang me from the same tree. But we have no requirement in the IETF to be constrained by their choices in designing a walled garden. Instead, we have a requirement to do the right thing for the Internet. And building services based on invisible mediators that preclude end-to-end transparency is NOT in the best interests of the Internet. -- 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 Mar 15 18:18:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfEm-0001DT-03; Wed, 15 Mar 2006 18:17:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfEk-0001DN-28 for sip@ietf.org; Wed, 15 Mar 2006 18:17:02 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJfEi-0003rQ-NB for sip@ietf.org; Wed, 15 Mar 2006 18:17:02 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 1EED6140411; Thu, 16 Mar 2006 01:16:58 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 6357C140407; Thu, 16 Mar 2006 01:16:53 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 57442F027F; Thu, 16 Mar 2006 01:17:21 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17432.41089.313369.873317@rautu.tutpro.com> Date: Thu, 16 Mar 2006 01:17:21 +0200 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <44189E1F.4090603@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 writes: > You have been talking as if preconditions are only for QoS. > There are now other defined uses. For instance there are security > preconditions, used to ensure that both sides know the keys and are able > to communicate securely before the phone rings. Do you have another way > to do that too? paul, so far only QoS has been mentioned, but the problem seems to be the same also with security: 180 Ringing comes from a secure leg followed by 200 OK from unsecure one. how does PRACK help you? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 15 18:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfFH-0001JY-0U; Wed, 15 Mar 2006 18:17:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfFF-0001JT-QO for sip@ietf.org; Wed, 15 Mar 2006 18:17:33 -0500 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJfFF-0003ry-AQ for sip@ietf.org; Wed, 15 Mar 2006 18:17:33 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2FNHUC16809; Wed, 15 Mar 2006 18:17:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 17:17:29 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E04CB@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHOHchwiZepEnEQKyOIw4lVBiYVQATjQNAAC2+QQAAAvjd0AAIkL4AAAYFBjA= From: "Brian Stucker" To: "Michael Hammer \(mhammer\)" , "Dean Willis" , "Cullen Jennings \(fluffy\)" X-Spam-Score: 0.1 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mike, I'm not trying to force a single-switch mentality, I'm just = using features that generally require a trusted third party to route the = call when the terminator is not around (like voicemail). The fact is that it is allowed by SIP (and I don't think you're required = to be a BBUA to retarget requests last I checked). So does that mean = that in order to solve this problem we must depricate certain provisions = in SIP? The example you give requires the terminator's call logic (ie. how long = and to whom the call should be redirected) is running on the = originator's client. It should not be up to the person making the call = to determine how the person they are calling wishes to have their calls = routed (or even know that their calls are being routed in a particular = manner). Not only that, but the recursion that is possible with a = redirect scenario like this seems to me to be ill-suited to a contact = header. A closer match would be a reverse history-info header (call it = the back-to-the-future-history-info header) that captures the tree-like = nature of the routing behavior prior to the routing occurring. I believe Dean mentioned sending CPL back (which seems more appropriate = than a back-to-the-future-history-info header). Obviously, nobody wants = their screening rules sent back that says "hey, it's you calling so just = route straight to voicemail because you're a pest" getting sent back to = the originator. Something needs to dynamically create the CPL or there = needs to be a way of obsfucating the request. That seems pretty complex = just to support retargeting a request. Finally, I there are many cases (especially in call center applications) = where you don't want the originator to know how to route the request to = the person that the call is being terminated to. This doesn't mean you = don't want them to know with whom they are speaking, just not how to = craft a request URI to get to them. I don't see how this is easily = possible with a redirection model unless we start handing out temporary = URLs to obsfucate where the request is going to get sent to. It seems like Dean's saying that the originator needs to know that = there's something in the middle mucking about with the routing of the = call because there's no way of differentiating between a network server = routing for the terminator and a MITM attack that's messing about with = the routing of the call. Are we considering secure transport to the = middle (SIP over TLS for example) to be enough to solve this scenario or = is more needed? Regards, Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Wednesday, March 15, 2006 2:13 PM To: Stucker, Brian [RICH1:B620:EXCH]; Dean Willis; Cullen Jennings (fluffy) Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat (pkyzivat) Subject: RE: [Sip] The Problem with PRACK The 302 can have multiple contacts. =20 The originator sends INVITE to the first contact,=20 and upon no answer sends to the second AoR. The thought is that the correct end result from user experience can occur,=20 maybe just no in the exact way, with exact node sequence as before,=20 with features in exactly the same place. I am just trying to escape a single switch mentality. Need to re-think all the features then. Mike =20 > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com]=20 > Sent: Wednesday, March 15, 2006 12:38 PM > To: Michael Hammer (mhammer); Dean Willis; Cullen Jennings (fluffy) > Cc: sip@ietf.org; Francois Audet; Paul Kyzivat (pkyzivat) > Subject: RE: [Sip] The Problem with PRACK >=20 > I don't know that I follow you suggestion in the specific=20 > case I am talking about. >=20 > Take for instance Call Forward No Answer. In this case, A=20 > never says that it's done with the call before it is=20 > retargeted to B by the network. A and B have no idea that the=20 > service even exists in the middle. >=20 > Regards, > Brian >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, March 15, 2006 8:42 AM > To: Stucker, Brian [RICH1:B620:EXCH]; Dean Willis; Cullen Jennings > (fluffy) > Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat > (pkyzivat) > Subject: RE: [Sip] The Problem with PRACK >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Brian Stucker [mailto:bstucker@nortel.com] > > Sent: Tuesday, March 14, 2006 11:55 AM > > To: Dean Willis; Cullen Jennings (fluffy) > > Cc: sip@ietf.org; Francois Audet; Paul Kyzivat (pkyzivat) > > Subject: RE: [Sip] The Problem with PRACK > >=20 > > Based on your proposals below, cryptographically transparent versus=20 > > redirection: > >=20 > > How would you go about addressing applications like CPL=20 > that need to=20 > > run timers for service logic and thus need to have some level of=20 > > control over the session (not necessarily what's in the body of the=20 > > messages, just where they're going) if a redirection model is used? > >=20 > > For example, without mucking about with what's inside the request,=20 > > triggering off of the request URI of an INVITE to forward to=20 > > destination A for X seconds and then to destination B. In=20 > this example=20 > > the next hop changes over time for the same request and=20 > does not seem=20 > > possible using redirection. This seems to preclude redirection as a=20 > > general solution and drive towards requiring a proxy to be=20 > > cryptographically transparent. >=20 > Is there a reason the redirect server couldn't send you to A,=20 > which then redirects or Refers you to B when A is done with=20 > it's part of the service? >=20 > It seems the proxy is best at directing traffic, while the=20 > UAS could contain distributed feature logic. Think of an=20 > assembly line of robots, each which knows its part of the=20 > process, but not necessarily the whole. >=20 > Mike >=20 > >=20 > > If the proxy is transparent, then how do you go about not=20 > precluding=20 > > deep-packet inspection issues raised by applications such as QoS=20 > > enforcement, network enforced identity or other services?=20 > It seems to=20 > > me that HTTPS may make a bad model in that I'm unaware of any=20 > > HTTPS-based application that has a box in the middle that needs to=20 > > inspect and enforce certain characteristics of the request=20 > before it=20 > > is handled by the final consumer of that request. > >=20 > > This seems to preclude cryptographic transparency as a general=20 > > solution. > >=20 > > I'm sure either can be used effectively in many application spaces,=20 > > but it does not seem that either can be used as a general=20 > solution in=20 > > the protocol itself. > >=20 > > Regards, > > Brian > >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, March 14, 2006 1:08 AM > > To: Cullen Jennings > > Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul H Kyzivat > > Subject: Re: [Sip] The Problem with PRACK > >=20 > >=20 > >=20 > > On Mar 14, 2006, at 12:24 AM, Cullen Jennings wrote: > >=20 > > > On 3/13/06 10:27 AM, "Dean Willis"=20 > > wrote: > > > > > >> Right. But, SIPS is only required as far as the proxy=20 > serving the=20 > > >> AOR. The AOR to Contact vector could be UDP/IPSEC, or even > > just plain > > >> unsecured UDP. > > > > > > I think we have a gathering amount of evidence that we want > > to update > > > this regardless of UDP or PRACK. > >=20 > >=20 > > It's true that SIP proxies just don't work "right" with=20 > SIPS as it is. > >=20 > > When people first look at the "SIPS is only valid to the serving=20 > > proxy" model they assume that simply changing the=20 > requirement to say=20 > > that the proxy-to-UA leg must also be SIPS protected would=20 > provide a=20 > > satisfactory answer. It doesn't, and this requires some careful=20 > > thinking. > >=20 > > What security do you mandate on the serving-proxy to UA link? TLS? =20 > > TLS supports many different ciphersuites. What keeps the=20 > crypto on the=20 > > SP-UA link from being watered-down? Would other protections=20 > like IPSEC=20 > > suffice? How would you end-to-end negotiate the=20 > cryptography so that=20 > > the originating UA could believe that the entire chain was=20 > protected=20 > > to some minimal level? And how do you offer some level of=20 > security to=20 > > an IMS fashion-victim who is always going to be exposed to MITM=20 > > attacks from his own service provider by design? > >=20 > > Personally, I think the only way SIPS really gives us the level of=20 > > protection we have come to expect from HTTPS is if it is=20 > used end-to-=20 > > end, either by abandoning proxy-routing in favor of a=20 > redirect model,=20 > > or by causing the proxies to be cryptographically transparent as is=20 > > done with HTTPS proxies. > >=20 > > This is an important thing to note: HTTPS proxies do NOT=20 > "see inside" > > the HTTPS stream. All they do is pass it along, unchanged,=20 > to the next=20 > > hop. It could actually be some other protocol than HTTP, and they=20 > > don't care and can't tell. To-date, we haven't treated SIPS proxies=20 > > that way, and instead presume they have access to the full=20 > stream, in=20 > > many cases "write access" so that they can munge various=20 > header fields=20 > > about. > >=20 > > -- > > Dean > >=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=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 15 18:30:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfQ0-0002gq-0m; Wed, 15 Mar 2006 18:28:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfPz-0002ga-1L for sip@ietf.org; Wed, 15 Mar 2006 18:28:39 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJfPy-000406-It for sip@ietf.org; Wed, 15 Mar 2006 18:28:38 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2FNOHT16838; Wed, 15 Mar 2006 18:24:17 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 17:28:34 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E04EB@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIhi0msXH4KoXUQ+i9YfEZFQ64sQAAMR/g From: "Brian Stucker" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 said. I think you may be assuming that I'm thinking only in terms of a class-5 = switch in the middle. I'm not. I'm also thinking of cases where you have = a simple proxy acting as an application layer router alone because for = reasons of privacy, clean call logic separation between the originating = and terminating party, and possibly network topology or security issues = the redirection cannot easily be done directly by the client initiating = the call. With redirection, I see these problems being solved with a "come back to = me again with a new request URI" list and some other meta-data that = describes timers, etc. The request URI may be obsfucated in a manner = that the routing privacy of the terminator is preserved, and by going = back through the proxy you get around the network topology issues. = However, I'm left with the increased messaging and non-separation of the = orig and term call models. Leaving DPI aside and focusing on this, any thoughts? Regards, Brian -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, March 15, 2006 5:14 PM To: Stucker, Brian [RICH1:B620:EXCH] Cc: Michael Hammer (mhammer); Cullen Jennings (fluffy); sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat (pkyzivat) Subject: Re: [Sip] The Problem with PRACK On Mar 15, 2006, at 4:45 PM, Brian Stucker wrote: > . . . > Seriously though, I don't think we can sit back and just say that =20 > this is a badly designed service. These are real services that =20 > exist in the real world that we all have to design and architect =20 > for in the near term. Sure we can. I'm fed up with being constrained by telecom-oriented =20 preconceived notions and ending up with compromised security, broken =20 implementations, and a headache that just won't quit. We can meet the =20 critical end-user requirements (it just works!) much more effectively =20 by tossing out badly designed services than by tossing out much-=20 needed principles. > Are you pushing for an RFC-2543 type revolution versus RFC-3261? Very little in the way of protocol change is needed. We will =20 eventually need to fix the "retargeting" design error that Jonathan =20 noted in his route-construction draft, but we believe this can be =20 done in a backward-compatible fashion. True, this does continue the =20 correction of request-routing design errors in RFC 2543 that started =20 with loose-routing in RFC 3261, but it's significantly less invasive. But we do need an ARCHITECTURAL revolution. We must STOP thinking =20 that we have a Class-5 switch controlling a bunch of call legs, and =20 START thinking we have intelligent endpoints connected to the Internet. > We also have many esteemed colleagues in 3GPP and 3GPP2 (amongst =20 > other groups) as you well know that allow and rely on deep packet =20 > inspection (like the P-CSCF and S-CSCF) with all sorts of service =20 > and routing interactions to boot. It seemed like in your earlier =20 > reply that you were suggesting that if a SIP proxy didn't change =20 > anything in the message other than the request URI and did it more =20 > than once that it should be a BBUA. Did I read you correctly? Actually, I'd say that if a SIP proxy really needs to change the =20 request URI (which is not the same as the request routing), then it =20 needs to be a B2BUA. And that most cases where we THINK we need to =20 change the request-URI can and should be accommodated by redirection. As for our colleagues who have consistently violated Internet design =20 principles in their architectures -- I'm sorry they did this. I tried =20 to warn them. Perhaps I didn't try hard enough, or simply failed to =20 communicate, and am guilty therefore of complicity. So hang me from =20 the same tree. But we have no requirement in the IETF to be constrained by their =20 choices in designing a walled garden. Instead, we have a requirement =20 to do the right thing for the Internet. And building services based =20 on invisible mediators that preclude end-to-end transparency is NOT =20 in the best interests of the Internet. -- 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 Mar 15 18:34:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfU5-0008Dd-IJ; Wed, 15 Mar 2006 18:32:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfU3-0007tk-LE for sip@ietf.org; Wed, 15 Mar 2006 18:32:51 -0500 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 1FJfU1-00044Z-BG for sip@ietf.org; Wed, 15 Mar 2006 18:32:51 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 15 Mar 2006 15:32:49 -0800 X-IronPort-AV: i="4.02,196,1139212800"; d="scan'208"; a="416116226:sNHT25445868" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2FNWm7T002381; Wed, 15 Mar 2006 15:32:48 -0800 (PST) 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.211); Wed, 15 Mar 2006 15:32:48 -0800 Received: from [10.21.97.124] ([10.21.97.124]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 15:32:48 -0800 Message-ID: <4418A41F.20803@cisco.com> Date: Wed, 15 Mar 2006 18:32:47 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] The Problem with PRACK References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> In-Reply-To: <17432.41089.313369.873317@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2006 23:32:48.0097 (UTC) FILETIME=[C4CA1D10:01C64888] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 Heinanen wrote: > Paul Kyzivat writes: > > > You have been talking as if preconditions are only for QoS. > > There are now other defined uses. For instance there are security > > preconditions, used to ensure that both sides know the keys and are able > > to communicate securely before the phone rings. Do you have another way > > to do that too? > > paul, > > so far only QoS has been mentioned, but the problem seems to be the same > also with security: 180 Ringing comes from a secure leg followed by > 200 OK from unsecure one. how does PRACK help you? Doesn't require forking at all. Consider Alice sends offerless invite to Bob. But Bob is only willing to do secure calls. So Bob returns an offer in a 183 with security preconditions. Bob needs an answer back that releases those preconditions before he is willing to ring, much less answer. 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 Wed Mar 15 18:46:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJffK-0001Au-Ig; Wed, 15 Mar 2006 18:44:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJffJ-0001Ap-TK for sip@ietf.org; Wed, 15 Mar 2006 18:44:29 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJffI-0004Dr-Gw for sip@ietf.org; Wed, 15 Mar 2006 18:44:29 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2FNioJw025263 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 17:44:51 -0600 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E04CB@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E04CB@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3940774D-5603-4235-9634-7AA5695AA810@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 17:44:23 -0600 To: "Brian Stucker" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 15, 2006, at 5:17 PM, Brian Stucker wrote: > The fact is that it is allowed by SIP (and I don't think you're > required to be a BBUA to retarget requests last I checked). So does > that mean that in order to solve this problem we must depricate > certain provisions in SIP? > Just because you CAN do something with SIP doesn't mean it;s a good idea to do it that way. > The example you give requires the terminator's call logic (ie. how > long and to whom the call should be redirected) is running on the > originator's client. It should not be up to the person making the > call to determine how the person they are calling wishes to have > their calls routed (or even know that their calls are being routed > in a particular manner). Not only that, but the recursion that is > possible with a redirect scenario like this seems to me to be ill- > suited to a contact header. A closer match would be a reverse > history-info header (call it the back-to-the-future-history-info > header) that captures the tree-like nature of the routing behavior > prior to the routing occurring. > > I believe Dean mentioned sending CPL back (which seems more > appropriate than a back-to-the-future-history-info header). > Obviously, nobody wants their screening rules sent back that says > "hey, it's you calling so just route straight to voicemail because > you're a pest" getting sent back to the originator. Something needs > to dynamically create the CPL or there needs to be a way of > obsfucating the request. That seems pretty complex just to support > retargeting a request. You might apply a first round of "CPL" in generating the redirecting response, disclosing only the part pertinent to the set of contacts that the specific caller might reach. > > Finally, I there are many cases (especially in call center > applications) where you don't want the originator to know how to > route the request to the person that the call is being terminated > to. This doesn't mean you don't want them to know with whom they > are speaking, just not how to craft a request URI to get to them. I > don't see how this is easily possible with a redirection model > unless we start handing out temporary URLs to obsfucate where the > request is going to get sent to. > Here you can redirect to a GRUU. If you REALLY need target anonymity, then the Contact coming back in a 200 OK would break your model anyhow, and you either need to use GRUU or use a B2BUA service. > It seems like Dean's saying that the originator needs to know that > there's something in the middle mucking about with the routing of > the call because there's no way of differentiating between a > network server routing for the terminator and a MITM attack that's > messing about with the routing of the call. Are we considering > secure transport to the middle (SIP over TLS for example) to be > enough to solve this scenario or is more needed? I don't consider "hopefully secure transitive TLS" to be all that satisfying. If something is changing the target of my call, I want to know WHO that something is and have a reason for TRUSTING it to make that change. In the world of browsing, it not infrequently happens that a user enters a URL for shopping site A, only to have their request answered by shopping site B. That's usually because somebody put some malware in their browser to hijack their HTTP shopping sessions. We consider that an attack. But at least the browsers (if TLS is used) give us a hint about where the session connected to. If "something in the middle of a SIP network" is hijacking my SIP sessions, I want to know about it, and I REALLY want to know that my session got to where I wanted it to go and not to a competitor or malefactor who may have paid my "service provider" to re-route the request, or just hacked them to achieve the same result. Consider the evolution of the mechanical phone switch -- it was supposedly invented because human operators had been subborned to divert calls from one mortuary to another competing mortuary, and the mortician who was losing business got mad: http://www.technologyreview.com/InfoTech/wtr_13959,258,p2.html We should learn from this -- TRUSTING the middlemen to do the right thing without VERIFYING that they have done so is likely to lead to one needing the services of a mortician, but perhaps getting something very different. -- 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 Mar 15 18:50:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfjs-0002i9-Vo; Wed, 15 Mar 2006 18:49:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfjr-0002i4-Aj for sip@ietf.org; Wed, 15 Mar 2006 18:49:11 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJfjq-0004In-1G for sip@ietf.org; Wed, 15 Mar 2006 18:49:11 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2FNnWFk025278 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 17:49:33 -0600 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E04EB@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E04EB@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6DE1A1FB-CAE9-4A30-A899-807E633C9BEA@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 17:49:05 -0600 To: "Brian Stucker" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 15, 2006, at 5:28 PM, Brian Stucker wrote: > Well said. Thanks. > I think you may be assuming that I'm thinking only in terms of a > class-5 switch in the middle. I'm not. I'm also thinking of cases > where you have a simple proxy acting as an application layer router > alone because for reasons of privacy, clean call logic separation > between the originating and terminating party, and possibly network > topology or security issues the redirection cannot easily be done > directly by the client initiating the call. > > With redirection, I see these problems being solved with a "come > back to me again with a new request URI" list and some other meta- > data that describes timers, etc. The request URI may be obsfucated > in a manner that the routing privacy of the terminator is > preserved, and by going back through the proxy you get around the > network topology issues. However, I'm left with the increased > messaging and non-separation of the orig and term call models. > > Leaving DPI aside and focusing on this, any thoughts? Yep. When you REALLY need that sort of obfuscation, you might really need a B2BUA, with media relay, and not a proxy service. If you're willing to reveal the actual endpoint's contact (which might be ephemeral), then redirection is adequate. And why should we have a separation of call models? Why should we even HAVE a "call model", as that is very much a PSTN term as it is usually applied? -- 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 Mar 15 18:54:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfnc-0003GS-P9; Wed, 15 Mar 2006 18:53:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfnb-0003GN-BN for sip@ietf.org; Wed, 15 Mar 2006 18:53:03 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJfna-0004Tw-1O for sip@ietf.org; Wed, 15 Mar 2006 18:53:03 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2FNrHbg025292 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 17:53:18 -0600 In-Reply-To: <4418A41F.20803@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54FCC73F-0A54-4EE8-B3C9-27C8C0D1E612@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 17:52:51 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org, Juha Heinanen , "Christer Holmberg \(JO/LMF\)" , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 15, 2006, at 5:32 PM, Paul Kyzivat wrote: > Consider Alice sends offerless invite to Bob. But Bob is only > willing to do secure calls. So Bob returns an offer in a 183 with > security preconditions. Bob needs an answer back that releases > those preconditions before he is willing to ring, much less answer. Off-the-wall response coming. How about: Bob redirects Alice to himself, along with a precondition qualifier. Alice satisfies the preconditions, then sends Bob a new INVITE that indicates the aforementioned preconditions have been satisfied. -- 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 Mar 15 18:55:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfoT-0003W4-M1; Wed, 15 Mar 2006 18:53:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJfoR-0003S0-HG for sip@ietf.org; Wed, 15 Mar 2006 18:53:55 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJfoR-0004VD-7d for sip@ietf.org; Wed, 15 Mar 2006 18:53:55 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1142466778!8353012!6 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 26992 invoked from network); 15 Mar 2006 23:53:52 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 15 Mar 2006 23:53:52 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 4401E00700259F30; Wed, 15 Mar 2006 18:53:51 -0500 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] The Problem with PRACK Date: Wed, 15 Mar 2006 17:53:52 -0600 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C413@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <6DE1A1FB-CAE9-4A30-A899-807E633C9BEA@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIizJxxDV/vio5Tzedk2SjTcy/GQAAEcZw From: "Dolly, Martin C, ALABS" To: "Dean Willis" , "Brian Stucker" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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, This has been a long chat. Can someone please summarize where we are at? Sorry for not reading all mails. Cheers, Martin > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, March 15, 2006 6:49 PM > To: Brian Stucker > Cc: Cullen Jennings (fluffy); sip@ietf.org; Francois Audet;=20 > Paul Kyzivat > (pkyzivat) > Subject: Re: [Sip] The Problem with PRACK >=20 >=20 >=20 > On Mar 15, 2006, at 5:28 PM, Brian Stucker wrote: >=20 > > Well said. >=20 > Thanks. >=20 > > I think you may be assuming that I'm thinking only in terms of a =20 > > class-5 switch in the middle. I'm not. I'm also thinking of cases =20 > > where you have a simple proxy acting as an application=20 > layer router =20 > > alone because for reasons of privacy, clean call logic separation =20 > > between the originating and terminating party, and possibly=20 > network =20 > > topology or security issues the redirection cannot easily be done =20 > > directly by the client initiating the call. > > > > With redirection, I see these problems being solved with a "come =20 > > back to me again with a new request URI" list and some other meta-=20 > > data that describes timers, etc. The request URI may be obsfucated =20 > > in a manner that the routing privacy of the terminator is =20 > > preserved, and by going back through the proxy you get around the =20 > > network topology issues. However, I'm left with the increased =20 > > messaging and non-separation of the orig and term call models. > > > > Leaving DPI aside and focusing on this, any thoughts? >=20 > Yep. When you REALLY need that sort of obfuscation, you might really =20 > need a B2BUA, with media relay, and not a proxy service. If you're =20 > willing to reveal the actual endpoint's contact (which might be =20 > ephemeral), then redirection is adequate. >=20 > And why should we have a separation of call models? Why should we =20 > even HAVE a "call model", as that is very much a PSTN term as it is =20 > usually applied? >=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 >=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 Mar 15 19:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJg0z-0006ST-2C; Wed, 15 Mar 2006 19:06:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJg0x-0006OH-R5 for sip@ietf.org; Wed, 15 Mar 2006 19:06:51 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJg0w-0004oV-Gl for sip@ietf.org; Wed, 15 Mar 2006 19:06:51 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2G07BmM025385 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Mar 2006 18:07:12 -0600 In-Reply-To: <28F05913385EAC43AF019413F674A0170DE0C413@OCCLUST04EVS1.ugd.att.com> References: <28F05913385EAC43AF019413F674A0170DE0C413@OCCLUST04EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 18:06:44 -0600 To: "Dolly, Martin C, ALABS" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 15, 2006, at 5:53 PM, Dolly, Martin C, ALABS wrote: > Hello, > > This has been a long chat. Can someone please summarize where we > are at? > Lost and wandering in the desert? > Sorry for not reading all mails. > Seriously, we've hit a couple of salient points. 1) PRACK is convoluted. It might can be simplified. Or maybe, we don't need it at all. We' have one thread discussing the requirements for and alternatives to preconditions. 2) Proxy retargeting remains "bad" and hop-by-hop TLS is questionable. That spun off a new thread on cryptotransparency at proxies, and a related thread on cryptoparticipant service models (including redirect) though the main PRACK thread occasionally raised arguments relevant to to this second discussion. 3) Slavish re-creation of PSTN service-switching modalities without regard to the practical realities of the Internet is a Really Bad Idea. -- 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 Mar 15 19:43:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJgYl-00010b-NZ; Wed, 15 Mar 2006 19:41:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJgYk-00010M-7n for sip@ietf.org; Wed, 15 Mar 2006 19:41:46 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJgYk-0005hV-0y for sip@ietf.org; Wed, 15 Mar 2006 19:41:46 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-5.tower-121.messagelabs.com!1142469674!7062046!8 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15006 invoked from network); 16 Mar 2006 00:41:45 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-121.messagelabs.com with SMTP; 16 Mar 2006 00:41:45 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 4401E0070025ACD2; Wed, 15 Mar 2006 19:41:44 -0500 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] The Problem with PRACK Date: Wed, 15 Mar 2006 18:41:44 -0600 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C415@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIjYhFqlkKeV7rTwi0xGWySQZ9fwABM71A From: "Dolly, Martin C, ALABS" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Always the sobering voice.... > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, March 15, 2006 7:07 PM > To: Dolly, Martin C, ALABS > Cc: Brian Stucker; Cullen Jennings (fluffy); sip@ietf.org; Francois > Audet; Paul Kyzivat (pkyzivat) > Subject: Re: [Sip] The Problem with PRACK >=20 >=20 >=20 > On Mar 15, 2006, at 5:53 PM, Dolly, Martin C, ALABS wrote: >=20 > > Hello, > > > > This has been a long chat. Can someone please summarize where we =20 > > are at? > > >=20 > Lost and wandering in the desert? >=20 > > Sorry for not reading all mails. > > >=20 > Seriously, we've hit a couple of salient points. >=20 > 1) PRACK is convoluted. It might can be simplified. Or maybe, we =20 > don't need it at all. We' have one thread discussing the=20 > requirements =20 > for and alternatives to preconditions. >=20 > 2) Proxy retargeting remains "bad" and hop-by-hop TLS is =20 > questionable. That spun off a new thread on cryptotransparency at =20 > proxies, and a related thread on cryptoparticipant service models =20 > (including redirect) though the main PRACK thread=20 > occasionally raised =20 > arguments relevant to to this second discussion. >=20 > 3) Slavish re-creation of PSTN service-switching modalities without =20 > regard to the practical realities of the Internet is a Really=20 > Bad Idea. >=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 Mar 15 20:37:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhP5-0003mA-Su; Wed, 15 Mar 2006 20:35:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhP4-0003li-Fr for sip@ietf.org; Wed, 15 Mar 2006 20:35:50 -0500 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJhP1-0007WK-7c for sip@ietf.org; Wed, 15 Mar 2006 20:35:50 -0500 Received: from [192.168.1.101] (pool-70-17-203-185.balt.east.verizon.net [70.17.203.185]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k2G1Zk308058 for ; Wed, 15 Mar 2006 19:35:46 -0600 From: "Frank W. Miller" To: sip@ietf.org In-Reply-To: <28F05913385EAC43AF019413F674A0170DE0C415@OCCLUST04EVS1.ugd.att.com> References: <28F05913385EAC43AF019413F674A0170DE0C415@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Wed, 15 Mar 2006 20:35:43 -0500 Message-Id: <1142472943.2727.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] PING draft update X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've updated the PING draft: draft-fwmiller-ping-02 http://www.cornfed.com/ping.txt http://www.cornfed.com/ping.html I made two changes. First, I took out the verbage about no retransmissions. A PING request initiates a standard NIT as before. I went back and looked at the NIT client side again and found that the max interval during requests retransmissions is actually 4 seconds. This means that the concern that a NAT binding might drop is unfounded if the stated assumption of 15 seconds is valid. Second, I added a paragraph on the potential expedited processing at the UAS that has been suggested. I'm also uploading the .txt version to the IETF side tonight. 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 Mar 15 20:50:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhb0-0005zs-5q; Wed, 15 Mar 2006 20:48:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhay-0005zn-Fw for sip@ietf.org; Wed, 15 Mar 2006 20:48:08 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJhay-0007fl-7H for sip@ietf.org; Wed, 15 Mar 2006 20:48:08 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 15 Mar 2006 17:48:07 -0800 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 k2G1m77T015014; Wed, 15 Mar 2006 17:48:07 -0800 (PST) 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.211); Wed, 15 Mar 2006 17:48:08 -0800 Received: from [10.21.90.12] ([10.21.90.12]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 17:48:06 -0800 Message-ID: <4418C3D6.3010508@cisco.com> Date: Wed, 15 Mar 2006 20:48:06 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] The Problem with PRACK References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <54FCC73F-0A54-4EE8-B3C9-27C8C0D1E612@softarmor.com> In-Reply-To: <54FCC73F-0A54-4EE8-B3C9-27C8C0D1E612@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2006 01:48:06.0996 (UTC) FILETIME=[AC07C940:01C6489B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, Juha Heinanen , "Christer Holmberg \(JO/LMF\)" , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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, I don't doubt that we could come up with some different model for how to do each thing that would be broken by deprecating PRACK. That means deprecating not only PRACK, but all the other RFCs and drafts that are dependent on it. I'm not sure how many of those there are, probably not a lot, but some. Each of those things will have to either be written off as a bad idea, or else redefined using some other mechanism. I guess if they are all bad ideas then this is clearly the right way to go. If some of those are still things that people want, then that makes more work to do. What you suggest below is a different way to do security preconditions. It could be the germ of a working scheme - or maybe it will be found to be flawed after further study. In any case it will take another cycle of draft development, attention units from ietf participants, and time at ietf meetings. Do we want that? Paul Dean Willis wrote: > > On Mar 15, 2006, at 5:32 PM, Paul Kyzivat wrote: > >> Consider Alice sends offerless invite to Bob. But Bob is only willing >> to do secure calls. So Bob returns an offer in a 183 with security >> preconditions. Bob needs an answer back that releases those >> preconditions before he is willing to ring, much less answer. > > > Off-the-wall response coming. > > How about: > > Bob redirects Alice to himself, along with a precondition qualifier. > Alice satisfies the preconditions, then sends Bob a new INVITE that > indicates the aforementioned preconditions have been satisfied. > > -- > 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 Mar 15 20:51:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhcI-0006Kj-Cq; Wed, 15 Mar 2006 20:49:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhcH-0006Ke-DS for sip@ietf.org; Wed, 15 Mar 2006 20:49:29 -0500 Received: from pproxy.gmail.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJhcF-0007hP-Uk for sip@ietf.org; Wed, 15 Mar 2006 20:49:29 -0500 Received: by pproxy.gmail.com with SMTP id n25so261171pyg for ; Wed, 15 Mar 2006 17:49:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=N3H8KYMmS98ffrDYRj48Z2ZIKgE6O6jyA4D0pp7Yn4fvTTdSCQL8PCt7qkEDPP5hToClzmggIj95/OOS6WdOKXKEKoXeZefrP2gEk7vKaz023ZG2iq7DiTe6b1KfGcdfy1etMEAqqYsJuojU8ZOUUy66vZxNadae6lNlI4D2bHM= Received: by 10.35.54.20 with SMTP id g20mr331162pyk; Wed, 15 Mar 2006 17:49:27 -0800 (PST) Received: by 10.35.58.20 with HTTP; Wed, 15 Mar 2006 17:49:27 -0800 (PST) Message-ID: <953beacc0603151749x4fdb2f73ibb32854d3f9385b@mail.gmail.com> Date: Wed, 15 Mar 2006 17:49:27 -0800 From: "Rohan Mahy" To: "Paul Kyzivat" Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <440F9719.4050307@cisco.com> MIME-Version: 1.0 References: <440E5E52.20500@cisco.com> <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> <440F9719.4050307@cisco.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f 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="===============0339173076==" Errors-To: sip-bounces@ietf.org --===============0339173076== Content-Type: multipart/alternative; boundary="----=_Part_5060_12084369.1142473767006" ------=_Part_5060_12084369.1142473767006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 3/8/06, Paul Kyzivat wrote: > > > 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I > > talked Jonathan into this, and I've been sorry I did ever since. My > > apologies to everyone for making a bad decision. > > As I mentioned elsewhere, if you deprecate this, then another way is > needed to answer an offer that comes in a reliable provisional. The only > obvious way would be to permit an answer in an UPDATE. For clarity, I am suggesting deprecating PRACK (offer) / 200 to PRACK (answer). I was no suggesting deprecating reliable 18x (offer) / PRACK (answer). thanks, -rohan > In any case, any change like this must be accompanied by a some strategy > for backward compatibility. This seems not so easy. As much as it is fun > to imagine how it might have been done better the first time around, I > suspect that at this point the cure is worse than the disease. > > Paul > > Paul > > > > > > Hope this helps. > > thanks, > > -rohan > > > > On 3/7/06, *Jonathan Rosenberg* > > wrote: > > > > At the last IETF, there was a lot of discussion and argument around > > PRACK. The spark of this debate was the ICE specification, which ha= d > > words in it requiring the usage of PRACK and UPDATE in order to wor= k > > with early media. There was strong pushback from many implementors > that > > anything requiring PRACK is unacceptable. Rohan put up a slide > (IIRC) > > that showed the state machine in his implementation resulting from > > PRACK, and it was not pretty. > > > > So, I'd like to discuss exactly what IS the problem with PRACK? > There > > are really two pieces of state machinery in play here. One piece is > the > > complication that PRACK introduces into the offer/answer model. Wit= h > > PRACK, you can now get a final answer in the 18x, and then send a > new > > offer in UPDATE, or even in PRACK itself. Another piece is the stat= e > > machinery with the retransmissions itself - correlating the PRACK > with a > > particular reliable provisional response and causing it to stop. > > > > In a chat with Flemming today, he suggested in interested remedy to > our > > PRACK dilemma. Why not revise PRACK so that you can't send an offer > or > > answer with it; it has no impact on the set of allowed O/A exchange= s > > defined by RFC 3261. I'm not sure if that would consequently break > the > > preconditions mechanism, but maybe there are some kind of > offer/answer > > limitations that would simplify things. > > > > So, this is one idea. I'd like for people who have complained about > > PRACK implementations to speak up and indicate what exactly makes i= t > so > > complicated for them. > > > > 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-500= 0 > > 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 > ------=_Part_5060_12084369.1142473767006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 3/8/06, Paul Kyzivat <pkyzivat@= cisco.com> wrote:
> 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. = ; I
> talked Jonathan into this, and I've been sorry I did ever = since.  My
> apologies to everyone for making a bad decisio= n.

As I mentioned elsewhere, if you deprecate this, then another way= is
needed to answer an offer that comes in a reliable provisional. The onl= y
obvious way would be to permit an answer in an UPDATE.

For clarity, I am suggesting deprecating PRACK (offer) / 200 to PRACK= (answer).  I was no suggesting deprecating reliable 18x (offer) / PRA= CK (answer).

thanks,
-rohan

 
In any case, any change like this must be accom= panied by a some strategy
for backward compatibility. This seems not so easy. As much as it is fu= n
to imagine how it might have been done better the first time around, I=
suspect that at this point the cure is worse than the disease.

        Paul

  &nb= sp;     Paul


>
> Hope this hel= ps.
> thanks,
> -rohan
>
> On 3/7/06, *Jonathan Ros= enberg* <jdrosen@cisco.com
&= gt; <mailto: jdrosen@cisco.com>> wrote:>
>     At the last IETF, there was a lot of= discussion and argument around
>     PRACK. The = spark of this debate was the ICE specification, which had
>     words in it requiring the usage of PRACK a= nd UPDATE in order to work
>     with early media= . There was strong pushback from many implementors that
>  =    anything requiring PRACK is unacceptable. Rohan put up a slide= (IIRC)
>     that showed the state machine in his imple= mentation resulting from
>     PRACK, and it was = not pretty.
>
>     So, I'd like to discuss= exactly what IS the problem with PRACK? There
>   &nb= sp; are really two pieces of state machinery in play here. One piece is the
>     complication that PRACK introduces into th= e offer/answer model. With
>     PRACK, you can n= ow get a final answer in the 18x, and then send a new
>  &n= bsp;  offer in UPDATE, or even in PRACK itself. Another piece is the s= tate
>     machinery with the retransmissions itself = - correlating the PRACK with a
>     particular r= eliable provisional response and causing it to stop.
>
> &= nbsp;   In a chat with Flemming today, he suggested in interested= remedy to our
>     PRACK dilemma. Why not revise PRACK so tha= t you can't send an offer or
>     answer with it= ; it has no impact on the set of allowed O/A exchanges
>  &= nbsp;  defined by RFC 3261. I'm not sure if that would consequently br= eak the
>     preconditions mechanism, but maybe there a= re some kind of offer/answer
>     limitations th= at would simplify things.
>
>     So, this = is one idea. I'd like for people who have complained about
>     PRACK implementations to speak up and indi= cate what exactly makes it so
>     complicated f= or them.
>
>     Thanks,
>  = ;   Jonathan R.
>     --
> &= nbsp;   Jonathan D. Rosenberg,=20 Ph.D.           &nbs= p;       600 Lanidex Plaza
>  = ;   Cisco Fellow        &= nbsp;           &nbs= p;            &= nbsp; Parsippany, NJ 07054-2711
>     Cisco Syste= ms
>     jdr= osen@cisco.com
>     <mailto:jdrosen@cisco.com>       &n= bsp;            = ;          FAX: &nbs= p; (973)
>     952-5050
>   =   http://www.jdrosen.net &= nbsp;           &nbs= p;           PHONE: (973)= 952-5000
>     http://ww= w.cisco.com
>
>     ___________________= ____________________________
>     Sip mailing li= st  https:= //www1.ietf.org/mailman/listinfo/sip
>     <https://www1.ietf.org/mailman/listinfo/sip>
= >     This list is for NEW development of the core S= IP Protocol
>     Use sip-implementors@cs.columbia.edu
>     <ma= ilto:sip-implementors@c= s.columbia.edu> for questions on current sip
>  &nbs= p;  Use sipping@ietf.org <mailto:sipping= @ietf.org> for new developments
>     on t= he application of sip
>
>
>
> ---------------------= ---------------------------------------------------
>
> _______________________________________________
> Si= p mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is f= or NEW development of the core SIP Protocol
> Use sip-implem= entors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on t= he application of sip

------=_Part_5060_12084369.1142473767006-- --===============0339173076== 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 --===============0339173076==-- From sip-bounces@ietf.org Wed Mar 15 21:48:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJiVd-0005r8-JS; Wed, 15 Mar 2006 21:46:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJiVb-0005qx-8y for sip@ietf.org; Wed, 15 Mar 2006 21:46:39 -0500 Received: from pproxy.gmail.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJiVZ-0000Z7-NY for sip@ietf.org; Wed, 15 Mar 2006 21:46:39 -0500 Received: by pproxy.gmail.com with SMTP id n25so276456pyg for ; Wed, 15 Mar 2006 18:46:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dwQhYh5fe6fXWxnA0JHVaaHoAXdh+mH8UTnC8txUryFd/KtbKYI+gTPJpTcSymtaDiHE6Jrrg/Eu+N2sjYhPoe5Ip3t4wxo46dMzlc85QtJAe1AxmLSmJCSpM1hOIdZHWYMZh/u1Y1P7RoXySBuKI773uXnoHiU9bIUDCPWv/Nc= Received: by 10.35.37.18 with SMTP id p18mr873689pyj; Wed, 15 Mar 2006 18:46:37 -0800 (PST) Received: by 10.35.58.20 with HTTP; Wed, 15 Mar 2006 18:46:36 -0800 (PST) Message-ID: <953beacc0603151846i57f6d3fdm4970043b8e3b9991@mail.gmail.com> Date: Wed, 15 Mar 2006 18:46:36 -0800 From: "Rohan Mahy" To: "Jonathan Rosenberg" Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> MIME-Version: 1.0 References: <440E5E52.20500@cisco.com> <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 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="===============2062328663==" Errors-To: sip-bounces@ietf.org --===============2062328663== Content-Type: multipart/alternative; boundary="----=_Part_5404_8430490.1142477196993" ------=_Part_5404_8430490.1142477196993 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Everyone, I went back over the 102 messages in this thread and did not hear any comments on my concrete proposals: - require RSeq to start at 1 - only acknowledge the most recent provisional. if the UAS wants to send as new provisional that completely replaces a previous one it can send immediately. if the UAS wants to send a new provisional but wants acknowledgement of a previous one, it has to wait for the PRACK. - send a provisional every 1 minute whether reliable or not. (instead of every one minute for unreliable and every 2.5 minutes for reliable) - deprecate *offers* in PRACK (answers are still OK) comments on *this*? thanks, -rohan On 3/8/06, Rohan Mahy wrote: > > Hi, > > A things about PRACK come immediately to mind that are a pain to > implement: > > 1) The UAS has to queue provisionals until it receives a PRACK for the > first provisional. This is due to RSeq starting at an arbitrary value > instead of just starting at 1. This is probably the simplest to fix, by > just requiring the UAC to always start with a RSeq of 1. > 2) Multiple unacknowledged provisionals can be in flight at the same time. > We could potentially eliminate this requirement by acknowledging the curr= ent > status instead of the whole history. In other words, when the UAS sends = a > new reliable provisional, it decides which (if any) of the previously sen= t > provisionals are still relevant and sends all of them (as sipfrags or > something) as a single reliable request. > > 3) If you "answer" and want to deliver a 200 OK, you have to queue it and > wait if you are waiting for a PRACK to an offer or answer. Keeping track = of > when you can send the 200 would be easier if we did something like I > recommend in #2. > > 4) Even for an acknowledged provisional, you still have to retransmit > approximately every minute (I forget exactly) to prevent old proxies from > deleting state for your transaction. This is one of those minor annoyanc= es > that is *almost* operationally irrelevant, and unlikely to not get coded. > My proposal for simplification is to retransmit the latest reliable > provisional in exactly the same way that the UAS retransmits unreliable > provisionals. Who cares if there is an extra message or two for a call w= ith > 1 minute + post-answer delay? > > 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I > talked Jonathan into this, and I've been sorry I did ever since. My > apologies to everyone for making a bad decision. > > Hope this helps. > thanks, > -rohan > > > On 3/7/06, Jonathan Rosenberg wrote: > > > > At the last IETF, there was a lot of discussion and argument around > > PRACK. The spark of this debate was the ICE specification, which had > > words in it requiring the usage of PRACK and UPDATE in order to work > > with early media. There was strong pushback from many implementors that > > anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) > > that showed the state machine in his implementation resulting from > > PRACK, and it was not pretty. > > > > So, I'd like to discuss exactly what IS the problem with PRACK? There > > are really two pieces of state machinery in play here. One piece is the > > complication that PRACK introduces into the offer/answer model. With > > PRACK, you can now get a final answer in the 18x, and then send a new > > offer in UPDATE, or even in PRACK itself. Another piece is the state > > machinery with the retransmissions itself - correlating the PRACK with = a > > particular reliable provisional response and causing it to stop. > > > > In a chat with Flemming today, he suggested in interested remedy to our > > PRACK dilemma. Why not revise PRACK so that you can't send an offer or > > answer with it; it has no impact on the set of allowed O/A exchanges > > defined by RFC 3261. I'm not sure if that would consequently break the > > preconditions mechanism, but maybe there are some kind of offer/answer > > limitations that would simplify things. > > > > So, this is one idea. I'd like for people who have complained about > > PRACK implementations to speak up and indicate what exactly makes it so > > complicated for them. > > > > Thanks, > > Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ 07054-271= 1 > > 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 > > > > ------=_Part_5404_8430490.1142477196993 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Everyone,

I went back over the 102 messages in this thread and di= d not hear any comments on my concrete proposals:

- require RSeq to = start at 1
- only acknowledge the most recent provisional. if the UAS wa= nts to send as new provisional that completely replaces a previous one it c= an send immediately.  if the UAS wants to send a new provisional but w= ants acknowledgement of a previous one, it has to wait for the PRACK.
- send a provisional every 1 minute whether reliable or not.  (in= stead of every one minute for unreliable and every 2.5 minutes for reliable= )
- deprecate *offers* in PRACK (answers are still OK)

comments o= n *this*?

thanks,
-rohan

On 3/8/06= , Rohan Mahy <rohan.mahy@gmail.com> wrote:
Hi,

A things about PRACK come immedia= tely to mind that are a pain to implement:

1) The UAS has to queue p= rovisionals until it receives a PRACK for the first provisional.  This= is due to RSeq starting at an arbitrary value instead of just starting at = 1.  This is probably the simplest to fix, by just requiring the UAC to= always start with a RSeq of 1.

2) Multiple unacknowledge= d provisionals can be in flight at the same time.  We could potentiall= y eliminate this requirement by acknowledging the current status instead of= the whole history.  In other words, when the UAS sends a new reliable= provisional, it decides which (if any) of the previously sent provisionals= are still relevant and sends all of them (as sipfrags or something) as a s= ingle reliable request.

3) If you "answer" and want to deliver a 200 OK, you have= to queue it and wait if you are waiting for a PRACK to an offer or answer.= Keeping track of when you can send the 200 would be easier if we did somet= hing like I recommend in #2. =20

4) Even for an acknowledged provisional, you still have to retransm= it approximately every minute (I forget exactly) to prevent old proxies fro= m deleting state for your transaction.  This is one of those minor ann= oyances that is *almost* operationally irrelevant, and unlikely to not get = coded.  My proposal for simplification is to retransmit the latest rel= iable provisional in exactly the same way that the UAS retransmits unreliab= le provisionals.  Who cares if there is an extra message or two for a = call with 1 minute + post-answer delay?

5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange.&n= bsp; I talked Jonathan into this, and I've been sorry I did ever since.&nbs= p; My apologies to everyone for making a bad decision.

Hope this hel= ps.
thanks,
-rohan


On 3/7/06, Jonathan Rosenberg <jdrosen@cis= co.com> wrote:
At the last IETF, there was a lot of discussion and argument around
PRAC= K. The spark of this debate was the ICE specification, which had
words i= n it requiring the usage of PRACK and UPDATE in order to work
with early= media. There was strong pushback from many implementors that
anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC)that showed the state machine in his implementation resulting from
PRA= CK, and it was not pretty.

So, I'd like to discuss exactly what IS t= he problem with PRACK? There
are really two pieces of state machinery in play here. One piece is the=
complication that PRACK introduces into the offer/answer model. WithPRACK, you can now get a final answer in the 18x, and then send a new
offer in UPDATE, or even in PRACK itself. Another piece is the state
mac= hinery with the retransmissions itself - correlating the PRACK with a
pa= rticular reliable provisional response and causing it to stop.

In a chat with Flemming today, he suggested in interested remedy to our
PRACK dilemma. Why not revise PRACK so that you can't send an offer or<= br>answer with it; it has no impact on the set of allowed O/A exchanges
= defined by RFC 3261. I'm not sure if that would consequently break the
preconditions mechanism, but maybe there are some kind of offer/answer
l= imitations that would simplify things.

So, this is one idea. I'd lik= e for people who have complained about
PRACK implementations to speak up= and indicate what exactly makes it so
complicated for them.

Thanks,
Jonathan R.
--
Jonathan D= . Rosenberg, Ph.D.         &nb= sp;         600 Lanidex Plaza
Ci= sco Fellow           = ;            &n= bsp;           Parsippany= , NJ 07054-2711
Cisco Systems
jdrosen@cisco.com  &= nbsp;           &nbs= p;            &= nbsp;  FAX:   (973) 952-5050
http://www.jdrosen.net        &= nbsp;           &nbs= p;    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.colum= bia.edu for questions on current sip
Use References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <54FCC73F-0A54-4EE8-B3C9-27C8C0D1E612@softarmor.com> <4418C3D6.3010508@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A2BD4B4-DEAE-4DCC-AE06-51B2E4E4384B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 21:16:32 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, Juha Heinanen , Brett Tate , "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 Mar 15, 2006, at 7:48 PM, Paul Kyzivat wrote: > Dean, > > I don't doubt that we could come up with some different model for > how to do each thing that would be broken by deprecating PRACK. > That means deprecating not only PRACK, but all the other RFCs and > drafts that are dependent on it. I'm not sure how many of those > there are, probably not a lot, but some. Each of those things will > have to either be written off as a bad idea, or else redefined > using some other mechanism. I guess if they are all bad ideas then > this is clearly the right way to go. If some of those are still > things that people want, then that makes more work to do. > > What you suggest below is a different way to do security > preconditions. It could be the germ of a working scheme - or maybe > it will be found to be flawed after further study. In any case it > will take another cycle of draft development, attention units from > ietf participants, and time at ietf meetings. Do we want that? > I hadn't suggested deprecating PRACK, though I believe Rohan had suggested simplifying it. I do believe that the preconditions model around PRACK has become over-used and top-heavy, and I wish we'd found a better way. Juha also made some suggestions on how to avoid using it. But rather than wrestling PRACK, I'd far rather we concentrate on cryptographic, service, and identity transparency, elimination of proxy retargeting, and fixing the proxy routing 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 Wed Mar 15 23:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJjfh-0006Na-G8; Wed, 15 Mar 2006 23:01:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJjfg-0006NV-2I for sip@ietf.org; Wed, 15 Mar 2006 23:01:08 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJjfd-00034Z-PX for sip@ietf.org; Wed, 15 Mar 2006 23:01:08 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 15 Mar 2006 20:01:07 -0800 X-IronPort-AV: i="4.02,196,1139212800"; d="scan'208"; a="1785389350:sNHT32195168" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2G415w1024336; Wed, 15 Mar 2006 20:01:05 -0800 (PST) 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.211); Wed, 15 Mar 2006 20:01:04 -0800 Received: from [10.21.90.12] ([10.21.90.12]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 20:01:04 -0800 Message-ID: <4418E2F9.5040001@cisco.com> Date: Wed, 15 Mar 2006 23:00:57 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] The Problem with PRACK References: <440E5E52.20500@cisco.com> <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> <440F9719.4050307@cisco.com> <953beacc0603151749x4fdb2f73ibb32854d3f9385b@mail.gmail.com> In-Reply-To: <953beacc0603151749x4fdb2f73ibb32854d3f9385b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2006 04:01:04.0622 (UTC) FILETIME=[3F10E8E0:01C648AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Rohan Mahy wrote: > > > On 3/8/06, *Paul Kyzivat* > wrote: > > > 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I > > talked Jonathan into this, and I've been sorry I did ever since. My > > apologies to everyone for making a bad decision. > > As I mentioned elsewhere, if you deprecate this, then another way is > needed to answer an offer that comes in a reliable provisional. The only > obvious way would be to permit an answer in an UPDATE. > > > For clarity, I am suggesting deprecating PRACK (offer) / 200 to PRACK > (answer). I was no suggesting deprecating reliable 18x (offer) / PRACK > (answer). Oh. I thought you were proposing abandoning PRACK entirely for offer/answer. (But I haven't really been tracking exactly who has advocated what.) The limited form you suggest is far less troublesome. OTOH, I still struggle to understand how removing existing features simplifies life for anyone. It only gets simpler for those that implement *only* the new way. So a deployment strategy is required that allows that. 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 Mar 16 00:04:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJkck-0008Ml-Fh; Thu, 16 Mar 2006 00:02:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJkcj-0008Mg-Ly for sip@ietf.org; Thu, 16 Mar 2006 00:02:09 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJkci-0004OK-9p for sip@ietf.org; Thu, 16 Mar 2006 00:02:09 -0500 Received: by tutpro.com (Postfix, from userid 65534) id B5A8B140418; Thu, 16 Mar 2006 07:02:06 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id B19AD140415; Thu, 16 Mar 2006 07:02:00 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id B6231F027F; Thu, 16 Mar 2006 07:02:27 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17432.61795.685205.596416@rautu.tutpro.com> Date: Thu, 16 Mar 2006 07:02:27 +0200 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <4418A41F.20803@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 writes: > Consider Alice sends offerless invite to Bob. But Bob is only willing to > do secure calls. So Bob returns an offer in a 183 with security > preconditions. Bob needs an answer back that releases those > preconditions before he is willing to ring, much less answer. how does that work with forking in the example i gave. you didn't answer. or are you saying that you deprecate forking in order to make your precondition stuff work? forking is one important value add of SIP over PSTN and i don't want to thought it away. i thought that IETF had defined some kind of KPI based system to identify callers. is that also gone? what comes to your example, why can't bob return back a 4xx response with security preconditions, the same way authentication works? -- 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 Thu Mar 16 00:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJkg9-00020j-0m; Thu, 16 Mar 2006 00:05:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJkg7-00020e-SK for sip@ietf.org; Thu, 16 Mar 2006 00:05:39 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJkg6-0004YK-Gm for sip@ietf.org; Thu, 16 Mar 2006 00:05:39 -0500 Received: by tutpro.com (Postfix, from userid 65534) id B75CE140418; Thu, 16 Mar 2006 07:05:37 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 23FE6140415; Thu, 16 Mar 2006 07:05:32 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 828A9F027F; Thu, 16 Mar 2006 07:05:58 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17432.62006.483903.565365@rautu.tutpro.com> Date: Thu, 16 Mar 2006 07:05:58 +0200 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <54FCC73F-0A54-4EE8-B3C9-27C8C0D1E612@softarmor.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <54FCC73F-0A54-4EE8-B3C9-27C8C0D1E612@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org, Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > Bob redirects Alice to himself, along with a precondition qualifier. > Alice satisfies the preconditions, then sends Bob a new INVITE that > indicates the aforementioned preconditions have been satisfied. this is similar to my 4xx response and would work too. it would be high time for stop inventing new messages and use what we already have got. current status of the discussion: no one has yet come up with any example that would require PRACK. also, the precondition stuff with 1xx seems to have serious problems with forking. -- 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 Thu Mar 16 00:24:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJkwh-0001pw-Qf; Thu, 16 Mar 2006 00:22:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJkwf-0001ec-VO for sip@ietf.org; Thu, 16 Mar 2006 00:22:45 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJkwf-0004xN-Kf for sip@ietf.org; Thu, 16 Mar 2006 00:22:45 -0500 Received: by tutpro.com (Postfix, from userid 65534) id F2544140418; Thu, 16 Mar 2006 07:22:44 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 5FBE6140415; Thu, 16 Mar 2006 07:22:39 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id D4A31F027F; Thu, 16 Mar 2006 07:23:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17432.63033.746949.505299@rautu.tutpro.com> Date: Thu, 16 Mar 2006 07:23:05 +0200 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <4418C3D6.3010508@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <54FCC73F-0A54-4EE8-B3C9-27C8C0D1E612@softarmor.com> <4418C3D6.3010508@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 writes: > That means deprecating not only PRACK, but all the other RFCs and > drafts that are dependent on it. the more goes the better. that gives implementers time to catch up and in the meanwhile SIP working group can do their laundry. > Do we want that? what we want is a small number of easy to understand/simple to implement specifications. why you got into this mess was that IETF had no guts to say NO to the walled garden based requirement from 3gpp. now it is high time do so. -- 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 Thu Mar 16 01:35:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJm2w-00025p-Dk; Thu, 16 Mar 2006 01:33:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJm2v-00025k-FG for sip@ietf.org; Thu, 16 Mar 2006 01:33:17 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJm2u-0006ji-6Z for sip@ietf.org; Thu, 16 Mar 2006 01:33:17 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 15 Mar 2006 22:33:16 -0800 X-IronPort-AV: i="4.02,196,1139212800"; d="scan'208"; a="1785412938:sNHT31588796" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2G6XEYg019246; Wed, 15 Mar 2006 22:33:15 -0800 (PST) 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.211); Wed, 15 Mar 2006 22:33:17 -0800 Received: from [10.21.90.12] ([10.21.90.12]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 22:33:14 -0800 Message-ID: <441906A9.2090802@cisco.com> Date: Thu, 16 Mar 2006 01:33:13 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] The Problem with PRACK References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <17432.61795.685205.596416@rautu.tutpro.com> In-Reply-To: <17432.61795.685205.596416@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2006 06:33:14.0378 (UTC) FILETIME=[80D31EA0:01C648C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 Heinanen wrote: > Paul Kyzivat writes: > > > Consider Alice sends offerless invite to Bob. But Bob is only willing to > > do secure calls. So Bob returns an offer in a 183 with security > > preconditions. Bob needs an answer back that releases those > > preconditions before he is willing to ring, much less answer. > > how does that work with forking in the example i gave. you didn't > answer. Sorry. I saw that but seem to have misplaced it. or are you saying that you deprecate forking in order to make > your precondition stuff work? forking is one important value add of SIP > over PSTN and i don't want to thought it away. No, I don't believe they conflict, any more than any other thing has problems with forking. > i thought that IETF had defined some kind of KPI based system to > identify callers. is that also gone? Huh? What does this have to do with the current discussion? > what comes to your example, why can't bob return back a 4xx response > with security preconditions, the same way authentication works? HERFP. Plus of course at the moment there is no such 4xx response. 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 Mar 16 01:43:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJmAt-0006lv-BW; Thu, 16 Mar 2006 01:41:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJmAr-0006lq-80 for sip@ietf.org; Thu, 16 Mar 2006 01:41:29 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJmAp-0006w4-VO for sip@ietf.org; Thu, 16 Mar 2006 01:41:29 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2006 22:41:27 -0800 X-IronPort-AV: i="4.02,196,1139212800"; d="scan'208"; a="262241185:sNHT31823100" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2G6fQYs020883; Wed, 15 Mar 2006 22:41:27 -0800 (PST) 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.211); Wed, 15 Mar 2006 22:41:16 -0800 Received: from [10.21.90.12] ([10.21.90.12]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 22:41:12 -0800 Message-ID: <44190887.9030705@cisco.com> Date: Thu, 16 Mar 2006 01:41:11 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] The Problem with PRACK References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <54FCC73F-0A54-4EE8-B3C9-27C8C0D1E612@softarmor.com> <17432.62006.483903.565365@rautu.tutpro.com> In-Reply-To: <17432.62006.483903.565365@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2006 06:41:12.0410 (UTC) FILETIME=[9DC103A0:01C648C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 Heinanen wrote: > Dean Willis writes: > > > Bob redirects Alice to himself, along with a precondition qualifier. > > Alice satisfies the preconditions, then sends Bob a new INVITE that > > indicates the aforementioned preconditions have been satisfied. > > this is similar to my 4xx response and would work too. it would be high > time for stop inventing new messages and use what we already have got. Well, I'm pretty sure PRACK was created before SUBSCRIBE. Does that mean that we should trash SUBSCRIBE too? > current status of the discussion: no one has yet come up with any > example that would require PRACK. also, the precondition stuff with 1xx > seems to have serious problems with forking. Nobody has come up with a case where PRACK can't be replaced by some other vaguely specified hypothetical new extension to sip. That isn't a fair comparison. Frankly, it would be fun to throw away everything that seems wrong with sip and just redesign everything based on the wisdom that has been gained. But I don't think that is going to fly. (Look at the much smaller goal of replacing SDP with SDPng.) So we are stuck for now with evolutionary changes. Incompatible changes are hard to do. 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 Mar 16 02:33:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJmxl-0001EY-V4; Thu, 16 Mar 2006 02:32:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJmxj-0001ET-Qg for sip@ietf.org; Thu, 16 Mar 2006 02:31:59 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJmxh-0008CH-6R for sip@ietf.org; Thu, 16 Mar 2006 02:31:59 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2G7WFIR027465 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 01:32:16 -0600 In-Reply-To: <17432.61795.685205.596416@rautu.tutpro.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <17432.61795.685205.596416@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 01:31:48 -0600 To: Juha Heinanen X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 15, 2006, at 11:02 PM, Juha Heinanen wrote: > Paul Kyzivat writes: > >> Consider Alice sends offerless invite to Bob. But Bob is only >> willing to >> do secure calls. So Bob returns an offer in a 183 with security >> preconditions. Bob needs an answer back that releases those >> preconditions before he is willing to ring, much less answer. > > how does that work with forking in the example i gave. you didn't > answer. or are you saying that you deprecate forking in order to make > your precondition stuff work? forking is one important value add > of SIP > over PSTN and i don't want to thought it away. > Well, we meet the preconditions at ALL the forked-to endpoints before Bob answers. > i thought that IETF had defined some kind of KPI based system to > identify callers. is that also gone? sip-identity? > > what comes to your example, why can't bob return back a 4xx response > with security preconditions, the same way authentication works? > That might work too - a new 4xx message that returns a key to be used later. Hmm. -- Dan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 02:52:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJnFT-0007ss-LQ; Thu, 16 Mar 2006 02:50:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJnFR-0007kx-TY for sip@ietf.org; Thu, 16 Mar 2006 02:50:17 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJnFQ-0008U2-JV for sip@ietf.org; Thu, 16 Mar 2006 02:50:17 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2G7oawI027550 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 01:50:37 -0600 In-Reply-To: <441906A9.2090802@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <17432.61795.685205.596416@rautu.tutpro.com> <441906A9.2090802@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <45C84134-9B75-4E45-AF67-F281607DBF6E@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 01:50:10 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sip@ietf.org, Juha Heinanen , "Christer Holmberg \(JO/LMF\)" , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 16, 2006, at 12:33 AM, Paul Kyzivat wrote: > >> what comes to your example, why can't bob return back a 4xx response >> with security preconditions, the same way authentication works? > > HERFP. > No, not if we could match the 4x to a contact-specific target for the followon request. -- 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 Mar 16 03:04:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJnR1-00023l-EV; Thu, 16 Mar 2006 03:02:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJnR0-00023e-1V for sip@ietf.org; Thu, 16 Mar 2006 03:02:14 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJnQv-0000G4-I1 for sip@ietf.org; Thu, 16 Mar 2006 03:02:14 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k2G81lsC018121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Mar 2006 09:01:47 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k2G81gCf012737; Thu, 16 Mar 2006 09:01:42 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k2G81amK012736; Thu, 16 Mar 2006 09:01:36 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 From: Hans Persson To: Dean Willis In-Reply-To: References: <44181E84.8070009@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Thu, 16 Mar 2006 09:01:35 +0100 Message-Id: <1142496095.11076.15.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Thu, 16 Mar 2006 09:01:47 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Cullen Jennings , "sip@ietf.org" , Michael Thomas X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ons 2006-03-15 klockan 16:36 -0600 skrev Dean Willis: > I believe it's an assertion that the call came from fluffy@cisco.com > signed not by cisco.com but by ingate.com. How do I make such an assertion within the framework of Identity? As far as I can tell, a UA compliant with identity-06 will reject such a request since the domain of the From header does not match the domain of the certificate of the signer. Or am I misunderstanding what you mean? > Do you trust ingate to > make this assertion? That's up the relationship you have with ingate. If ingate.com is my own domain (handling my own outgoing Identity headers, for instance), then I would trust it to make this kind of assertion. If, however, it is a third-party domain that happens to be in the signaling path, then I probably won't put much trust in such an assumption. > I trust it a lot MORE if ingate is cryptoparticipant and I've > validated the message source than if it just comes in out of the > blue, but I still don't trust it a whole lot. That's a large part of > why B2BUA solutions have EXTREMELY LIMITED APPLICABILITY and we don't > design ANYTHING around them but conferencing-like services. What I feel will limit the deployability of Identity is that it states in the requirements in Appendix C "the mechanism must be capable of protecting the integrity of SIP message bodies", while what is defined in identity-06 is something like "the mechanism must protect the integrity of SIP message bodies". Not just an option to do it, but actually no option but to do it. Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 03:17:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJndR-0004PF-Ml; Thu, 16 Mar 2006 03:15:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJndR-0004Ox-0V for sip@ietf.org; Thu, 16 Mar 2006 03:15:05 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJndL-0000Pn-PI for sip@ietf.org; Thu, 16 Mar 2006 03:15:02 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4D6214F0003; Thu, 16 Mar 2006 09:14:07 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 09:14:06 +0100 Received: from [136.225.183.113] ([136.225.183.113]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 09:14:03 +0100 From: "Christer Holmberg" To: "Arunachalam Venkatraman (arunvenk)" Subject: RE: [Sip] The Problem with PRACK (18x queuwing) Date: Thu, 16 Mar 2006 10:09:12 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 16 Mar 2006 08:14:06.0334 (UTC) FILETIME=[981251E0:01C648D1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, That is exactly my point. If the UAC in the INVITE indicates that the first = value MUST be 2 (your example), and the UAC then receives 3, it KNOWS the 2 = hasn't arrived yet. 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 Mar 16 03:56:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoFG-0005yq-32; Thu, 16 Mar 2006 03:54:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoEv-0005bQ-1H for sip@ietf.org; Thu, 16 Mar 2006 03:53:49 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJo9T-0000ru-Qf for sip@ietf.org; Thu, 16 Mar 2006 03:48:15 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2G8m8u04485; Thu, 16 Mar 2006 03:48:09 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 02:47:50 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AE7BC71@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIpAaITcQrbSyST8Cpv4BPfpnTywAMQARw From: "Samir Srivastava" To: "Rohan Mahy" X-Spam-Score: 0.1 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 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="===============0875365607==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0875365607== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C648D6.503CB03D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C648D6.503CB03D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Where do we stand for deprecating PRACK for e2e reliable transport ? =20 Should we wait for other problems to be fixed first (i.e. SDP is offer /answer indication or UPDATE with answer). By the time it is fixed, we have PRACK already widely implemented and used on e2e reliable transports. Shouldn't these two go in parallel ? =20 Thx Samir ________________________________ From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 Sent: Wednesday, March 15, 2006 6:47 PM To: Jonathan Rosenberg Cc: IETF SIP List Subject: Re: [Sip] The Problem with PRACK Hi Everyone, I went back over the 102 messages in this thread and did not hear any comments on my concrete proposals: - require RSeq to start at 1 - only acknowledge the most recent provisional. if the UAS wants to send as new provisional that completely replaces a previous one it can send immediately. if the UAS wants to send a new provisional but wants acknowledgement of a previous one, it has to wait for the PRACK.=20 - send a provisional every 1 minute whether reliable or not. (instead of every one minute for unreliable and every 2.5 minutes for reliable) - deprecate *offers* in PRACK (answers are still OK) comments on *this*?=20 thanks, -rohan On 3/8/06, Rohan Mahy wrote:=20 Hi, =09 A things about PRACK come immediately to mind that are a pain to implement: =09 1) The UAS has to queue provisionals until it receives a PRACK for the first provisional. This is due to RSeq starting at an arbitrary value instead of just starting at 1. This is probably the simplest to fix, by just requiring the UAC to always start with a RSeq of 1.=20 2) Multiple unacknowledged provisionals can be in flight at the same time. We could potentially eliminate this requirement by acknowledging the current status instead of the whole history. In other words, when the UAS sends a new reliable provisional, it decides which (if any) of the previously sent provisionals are still relevant and sends all of them (as sipfrags or something) as a single reliable request.=20 =09 3) If you "answer" and want to deliver a 200 OK, you have to queue it and wait if you are waiting for a PRACK to an offer or answer. Keeping track of when you can send the 200 would be easier if we did something like I recommend in #2. =20 =09 4) Even for an acknowledged provisional, you still have to retransmit approximately every minute (I forget exactly) to prevent old proxies from deleting state for your transaction. This is one of those minor annoyances that is *almost* operationally irrelevant, and unlikely to not get coded. My proposal for simplification is to retransmit the latest reliable provisional in exactly the same way that the UAS retransmits unreliable provisionals. Who cares if there is an extra message or two for a call with 1 minute + post-answer delay?=20 =09 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange. I talked Jonathan into this, and I've been sorry I did ever since. My apologies to everyone for making a bad decision. =09 Hope this helps. thanks, =09 -rohan =09 =09 =09 On 3/7/06, Jonathan Rosenberg wrote:=20 At the last IETF, there was a lot of discussion and argument around PRACK. The spark of this debate was the ICE specification, which had words in it requiring the usage of PRACK and UPDATE in order to work with early media. There was strong pushback from many implementors that=20 anything requiring PRACK is unacceptable. Rohan put up a slide (IIRC) that showed the state machine in his implementation resulting from PRACK, and it was not pretty. =09 So, I'd like to discuss exactly what IS the problem with PRACK? There=20 are really two pieces of state machinery in play here. One piece is the complication that PRACK introduces into the offer/answer model. With PRACK, you can now get a final answer in the 18x, and then send a new=20 offer in UPDATE, or even in PRACK itself. Another piece is the state machinery with the retransmissions itself - correlating the PRACK with a particular reliable provisional response and causing it to stop. =09 In a chat with Flemming today, he suggested in interested remedy to our=20 PRACK dilemma. Why not revise PRACK so that you can't send an offer or answer with it; it has no impact on the set of allowed O/A exchanges defined by RFC 3261. I'm not sure if that would consequently break the=20 preconditions mechanism, but maybe there are some kind of offer/answer limitations that would simplify things. =09 So, this is one idea. I'd like for people who have complained about PRACK implementations to speak up and indicate what exactly makes it so=20 complicated for them. =09 Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems=20 jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip =20 This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C648D6.503CB03D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Where do we stand for deprecating PRACK for = e2e=20 reliable transport ?
 
Should we wait for other problems to be fixed = first=20 (i.e. SDP is offer /answer indication or UPDATE with answer). By the = time it is=20 fixed,
we have PRACK already widely implemented and = used on=20 e2e reliable transports. Shouldn't these two go in parallel=20 ?
 
Thx
Samir

From: Rohan Mahy = [mailto:rohan.mahy@gmail.com]=20
Sent: Wednesday, March 15, 2006 6:47 PM
To: = Jonathan=20 Rosenberg
Cc: IETF SIP List
Subject: Re: [Sip] The = Problem=20 with PRACK

Hi Everyone,

I went back over the 102 messages in this = thread=20 and did not hear any comments on my concrete proposals:

- require = RSeq to=20 start at 1
- only acknowledge the most recent provisional. if the UAS = wants=20 to send as new provisional that completely replaces a previous one it = can send=20 immediately.  if the UAS wants to send a new provisional but wants=20 acknowledgement of a previous one, it has to wait for the PRACK.
- = send a=20 provisional every 1 minute whether reliable or not.  (instead of = every one=20 minute for unreliable and every 2.5 minutes for reliable)
- deprecate = *offers* in PRACK (answers are still OK)

comments on *this*?=20

thanks,
-rohan

On 3/8/06, Rohan Mahy=20 <rohan.mahy@gmail.com> = wrote:
Hi,

A things about PRACK come = immediately=20 to mind that are a pain to implement:

1) The UAS has to queue=20 provisionals until it receives a PRACK for the first = provisional.  This=20 is due to RSeq starting at an arbitrary value instead of just starting = at=20 1.  This is probably the simplest to fix, by just requiring the = UAC to=20 always start with a RSeq of 1.

2) Multiple unacknowledged provisionals = can be in=20 flight at the same time.  We could potentially eliminate this = requirement=20 by acknowledging the current status instead of the whole = history.  In=20 other words, when the UAS sends a new reliable provisional, it decides = which=20 (if any) of the previously sent provisionals are still relevant and = sends all=20 of them (as sipfrags or something) as a single reliable request. =

3) If=20 you "answer" and want to deliver a 200 OK, you have to queue it and = wait if=20 you are waiting for a PRACK to an offer or answer. Keeping track of = when you=20 can send the 200 would be easier if we did something like I recommend = in=20 #2. 

4) Even for an acknowledged provisional, you still = have to=20 retransmit approximately every minute (I forget exactly) to prevent = old=20 proxies from deleting state for your transaction.  This is one of = those=20 minor annoyances that is *almost* operationally irrelevant, and = unlikely to=20 not get coded.  My proposal for simplification is to retransmit = the=20 latest reliable provisional in exactly the same way that the UAS = retransmits=20 unreliable provisionals.  Who cares if there is an extra message = or two=20 for a call with 1 minute + post-answer delay?

5) I would = deprecate the=20 PRACK/200 (PRACK) offer/answer exchange.  I talked Jonathan into = this,=20 and I've been sorry I did ever since.  My apologies to everyone = for=20 making a bad decision.

Hope this helps.
thanks,
-rohan


On 3/7/06, Jonathan=20 Rosenberg <jdrosen@cisco.com>=20 wrote:
At=20 the last IETF, there was a lot of discussion and argument = around
PRACK.=20 The spark of this debate was the ICE specification, which = had
words in it=20 requiring the usage of PRACK and UPDATE in order to work
with = early=20 media. There was strong pushback from many implementors that =
anything=20 requiring PRACK is unacceptable. Rohan put up a slide (IIRC)
that = showed=20 the state machine in his implementation resulting from
PRACK, and = it was=20 not pretty.

So, I'd like to discuss exactly what IS the = problem with=20 PRACK? There
are really two pieces of state machinery in play = here. One=20 piece is the
complication that PRACK introduces into the = offer/answer=20 model. With
PRACK, you can now get a final answer in the 18x, and = then=20 send a new
offer in UPDATE, or even in PRACK itself. Another = piece is=20 the state
machinery with the retransmissions itself - correlating = the=20 PRACK with a
particular reliable provisional response and causing = it to=20 stop.

In a chat with Flemming today, he suggested in = interested=20 remedy to our
PRACK dilemma. Why not revise PRACK so that you = can't send=20 an offer or
answer with it; it has no impact on the set of = allowed O/A=20 exchanges
defined by RFC 3261. I'm not sure if that would = consequently=20 break the
preconditions mechanism, but maybe there are some kind = of=20 offer/answer
limitations that would simplify things.

So, = this is=20 one idea. I'd like for people who have complained about
PRACK=20 implementations to speak up and indicate what exactly makes it so=20
complicated for them.

Thanks,
Jonathan = R.
--
Jonathan D.=20 Rosenberg,=20 = Ph.D.           &n= bsp;      =20 600 Lanidex Plaza
Cisco=20 = Fellow           &= nbsp;           &n= bsp;          =20 Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com      =             &= nbsp;           FA= X:  =20 (973) 952-5050
http://www.jdrosen.net     &= nbsp;           &n= bsp;      =20 PHONE: (973) 952-5000
http://www.cisco.com

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


= ------_=_NextPart_001_01C648D6.503CB03D-- --===============0875365607== 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 --===============0875365607==-- From sip-bounces@ietf.org Thu Mar 16 04:47:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJp38-00005e-RY; Thu, 16 Mar 2006 04:45:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJp38-00005N-6v for sip@ietf.org; Thu, 16 Mar 2006 04:45:42 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJp37-000387-TV for sip@ietf.org; Thu, 16 Mar 2006 04:45:42 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2G9jSi8011452; Thu, 16 Mar 2006 03:45:29 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Mar 2006 09:45:28 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0124F94D5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Erkki.Koivusalo@nokia.com, jh@tutpro.com Subject: RE: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 09:45:27 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org, pkyzivat@cisco.com, princeap@gmail.com, christer.holmberg@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 I must support Erkki on this. I'm afraid you cannot just deprecate part of the SIP 2.0 protocol just like that, particularly when there are implementations out there that support it. Moreover it is appropriate to currently build equipment that always requires both 100rel and precondition, to work on systems and with other end terminals that supposedly support it. This introduces a major backwards compatibility problem if such extensions are just deprecated. Moreover, 3GPP has worked in conjunction with IETF to meet certain requirements so that the evolution of SIP has remained with IETF. It is not possible to say that 3GPP should go away and develop their own solution, as that would break the current 3GPP compliance with the SIP changes procedures. Any replacement is almost certain to require usage of option tags, and that requires a standards track IETF document. If PRACK is bad, and I have not yet seen any technical evidence provided against it except that potentially it is hard to implement right, then one must ensure: - that operation by existing implementarions has some sort of fallback behaviour. - that any replacement displays some sort appropriate interworking with existing implementations. Otherwise I'm afraid from my perspective its a SIP 3.0 issue. I would say that I understand that usage of this extension very much depends on the media being negotiated, and on the bearer mechanisms used to support that media. The reason why usage in 3GPP has become optional (to the UAC) in release 6 in that it is very difficult to define when exactly it should be used. For negotiating MSRP as a media, it is highly likely it is not needed. For voice as a media with a charging model based on what the PSTN does now, or a charging model based on the bandwidth allocated at any time on the access, 100rel and preconditions stand a good chance of being used. There are lots of shades inbetween where it is very difficult to come up with a definitive answer. regards Keith > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] > Sent: 15 March 2006 09:29 > To: jh@tutpro.com > Cc: sip@ietf.org; pkyzivat@cisco.com; princeap@gmail.com; > christer.holmberg@ericsson.com > Subject: RE: [Sip] The Problem with PRACK > > > Hi, > > I do not agree it would be great to make sure that the > mobile SIP applications would never be able to interoperate > with those applications running in desktop PCs. > > I see signs towards other kind of direction (fixed IP network > operators planning to provide access towards 3G IMS, some PC > vendors planning to add SIM card support to laptops etc.) So > that is why I hope solutions could be found that satisfy the > needs of Internet as a whole, including the way how 3G networks > are aiming to provide the access to it. > > In 3GPP they have tried to do their specifications so that > the applications would be compliant to Internet world based > on IETF specifications, so that e.g. multimedia sharing would > be possible between a mobile phone and a PC. Preconditions is > one of the few specs created within IETF that 3GPP has originally > mandated due to radio access specific reasons, but they have > relaxed this requirement to be a preferred option. Anyway since > offer/answer and preconditions is one of the cornerstones in > 3GPP specifications, any backwards incompatible changes for those > specs will have a major impact to that community. In my opinion > this is one of the views (amongst many other important ones) > worth considering in this discussion. > > Regards, > > Erkki > > >-----Original Message----- > >From: ext Juha Heinanen [mailto:jh@tutpro.com] > >Sent: 15.March.2006 10:55 > >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) > >Cc: christer.holmberg@ericsson.com; pkyzivat@cisco.com; > >princeap@gmail.com; sip@ietf.org > >Subject: RE: [Sip] The Problem with PRACK > > > >Erkki.Koivusalo@nokia.com writes: > > > > > I agree with you. But this far it has been possible and > > > there are implementations using that option, for specific > > > reasons. I did not intend to tell more than that and still > > > think it was relevant input for this discussion. > > > >my suggestion is that PRACK is deprecated and if mobile vendors still > >need it, they can solve the problems on 3gpp mailing lists. > > > >-- 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 Thu Mar 16 05:29:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJpi3-0006rB-F1; Thu, 16 Mar 2006 05:27:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJpi2-0006r6-D7 for sip@ietf.org; Thu, 16 Mar 2006 05:27:58 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJpi1-0004e9-1R for sip@ietf.org; Thu, 16 Mar 2006 05:27:58 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 57453140418; Thu, 16 Mar 2006 12:27:55 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 51A2C140415; Thu, 16 Mar 2006 12:27:48 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 9325AF027F; Thu, 16 Mar 2006 12:28:14 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17433.15806.520993.376972@rautu.tutpro.com> Date: Thu, 16 Mar 2006 12:28:14 +0200 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <44190887.9030705@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <54FCC73F-0A54-4EE8-B3C9-27C8C0D1E612@softarmor.com> <17432.62006.483903.565365@rautu.tutpro.com> <44190887.9030705@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 writes: > Well, I'm pretty sure PRACK was created before SUBSCRIBE. Does that mean > that we should trash SUBSCRIBE too? if you could have implemented same functionality with existing SIP requests, which is not likely with subscribe, but is likely with PRACK. > Nobody has come up with a case where PRACK can't be replaced by some > other vaguely specified hypothetical new extension to sip. That isn't a > fair comparison. you can dump PRACK for resource reservation without ANY extension to SIP as i have shown in earlier messages. it was 3gpp folks that defended PRACK on the basis of resource reservation, and they claims turned out to be false. > So we are stuck for now with evolutionary changes. Incompatible changes > are hard to do. evolution in should also mean deprecating bad ideas, not all the time adding new RFCs to the pile. -- 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 Thu Mar 16 05:36:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJpoC-00031H-Nh; Thu, 16 Mar 2006 05:34:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJpoB-00031C-Q2 for sip@ietf.org; Thu, 16 Mar 2006 05:34:19 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJpoB-0004jK-FM for sip@ietf.org; Thu, 16 Mar 2006 05:34:19 -0500 Received: by tutpro.com (Postfix, from userid 65534) id DF174140418; Thu, 16 Mar 2006 12:34:18 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 73E23140415; Thu, 16 Mar 2006 12:34:13 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 90F45F027F; Thu, 16 Mar 2006 12:34:42 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17433.16194.547665.704204@rautu.tutpro.com> Date: Thu, 16 Mar 2006 12:34:42 +0200 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] The Problem with PRACK In-Reply-To: References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <17432.61795.685205.596416@rautu.tutpro.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > Well, we meet the preconditions at ALL the forked-to endpoints before > Bob answers. i didn't ask about answering, but when does bob's phone start to ring? when it has got first 180 with accepted preconditions? > sip-identity? yes, i was thinking of some IETF spec that lets the callee to verify using PKI who is calling. perhaps such beast doesn't exist. > That might work too - a new 4xx message that returns a key to be used > later. Hmm. your 3xx idea was better. -- 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 Thu Mar 16 05:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJpt6-0006yZ-U4; Thu, 16 Mar 2006 05:39:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZxD-000348-L7 for sip@ietf.org; Wed, 15 Mar 2006 12:38:35 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJZxD-0000Xl-8d for sip@ietf.org; Wed, 15 Mar 2006 12:38:35 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2FHcVl03943; Wed, 15 Mar 2006 12:38:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 11:38:27 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710D67E9A1@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHOHchwiZepEnEQKyOIw4lVBiYVQATjQNAAC2+QQAAAvjd0A== From: "Brian Stucker" To: "Michael Hammer \(mhammer\)" , "Dean Willis" , "Cullen Jennings \(fluffy\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 X-Mailman-Approved-At: Thu, 16 Mar 2006 05:39:24 -0500 Cc: sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 that I follow you suggestion in the specific case I am = talking about. Take for instance Call Forward No Answer. In this case, A never says = that it's done with the call before it is retargeted to B by the = network. A and B have no idea that the service even exists in the = middle. Regards, Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Wednesday, March 15, 2006 8:42 AM To: Stucker, Brian [RICH1:B620:EXCH]; Dean Willis; Cullen Jennings (fluffy) Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat (pkyzivat) Subject: RE: [Sip] The Problem with PRACK =20 > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com]=20 > Sent: Tuesday, March 14, 2006 11:55 AM > To: Dean Willis; Cullen Jennings (fluffy) > Cc: sip@ietf.org; Francois Audet; Paul Kyzivat (pkyzivat) > Subject: RE: [Sip] The Problem with PRACK >=20 > Based on your proposals below, cryptographically transparent=20 > versus redirection: >=20 > How would you go about addressing applications like CPL that=20 > need to run timers for service logic and thus need to have=20 > some level of control over the session (not necessarily=20 > what's in the body of the messages, just where they're going)=20 > if a redirection model is used? >=20 > For example, without mucking about with what's inside the=20 > request, triggering off of the request URI of an INVITE to=20 > forward to destination A for X seconds and then to=20 > destination B. In this example the next hop changes over time=20 > for the same request and does not seem possible using=20 > redirection. This seems to preclude redirection as a general=20 > solution and drive towards requiring a proxy to be=20 > cryptographically transparent. Is there a reason the redirect server couldn't send you to A,=20 which then redirects or Refers you to B when A is done with=20 it's part of the service? It seems the proxy is best at directing traffic, while the UAS could contain distributed feature logic. Think of an assembly line of robots, each which knows its part of the process, but=20 not necessarily the whole. Mike >=20 > If the proxy is transparent, then how do you go about not=20 > precluding deep-packet inspection issues raised by=20 > applications such as QoS enforcement, network enforced=20 > identity or other services? It seems to me that HTTPS may=20 > make a bad model in that I'm unaware of any HTTPS-based=20 > application that has a box in the middle that needs to=20 > inspect and enforce certain characteristics of the request=20 > before it is handled by the final consumer of that request. >=20 > This seems to preclude cryptographic transparency as a=20 > general solution.=20 >=20 > I'm sure either can be used effectively in many application=20 > spaces, but it does not seem that either can be used as a=20 > general solution in the protocol itself. >=20 > Regards, > Brian >=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, March 14, 2006 1:08 AM > To: Cullen Jennings > Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul H Kyzivat > Subject: Re: [Sip] The Problem with PRACK >=20 >=20 >=20 > On Mar 14, 2006, at 12:24 AM, Cullen Jennings wrote: >=20 > > On 3/13/06 10:27 AM, "Dean Willis"=20 > wrote: > > > >> Right. But, SIPS is only required as far as the proxy serving the=20 > >> AOR. The AOR to Contact vector could be UDP/IPSEC, or even=20 > just plain=20 > >> unsecured UDP. > > > > I think we have a gathering amount of evidence that we want=20 > to update=20 > > this regardless of UDP or PRACK. >=20 >=20 > It's true that SIP proxies just don't work "right" with SIPS as it is. >=20 > When people first look at the "SIPS is only valid to the=20 > serving proxy" model they assume that simply changing the=20 > requirement to say that the proxy-to-UA leg must also be SIPS=20 > protected would provide a satisfactory answer. It doesn't,=20 > and this requires some careful thinking. >=20 > What security do you mandate on the serving-proxy to UA link? TLS? =20 > TLS supports many different ciphersuites. What keeps the=20 > crypto on the SP-UA link from being watered-down? Would other=20 > protections like IPSEC suffice? How would you end-to-end=20 > negotiate the cryptography so that the originating UA could=20 > believe that the entire chain was protected to some minimal=20 > level? And how do you offer some level of security to an IMS=20 > fashion-victim who is always going to be exposed to MITM=20 > attacks from his own service provider by design? >=20 > Personally, I think the only way SIPS really gives us the=20 > level of protection we have come to expect from HTTPS is if=20 > it is used end-to- end, either by abandoning proxy-routing in=20 > favor of a redirect model, or by causing the proxies to be=20 > cryptographically transparent as is done with HTTPS proxies. >=20 > This is an important thing to note: HTTPS proxies do NOT "see=20 > inside" =20 > the HTTPS stream. All they do is pass it along, unchanged, to=20 > the next hop. It could actually be some other protocol than=20 > HTTP, and they don't care and can't tell. To-date, we haven't=20 > treated SIPS proxies that way, and instead presume they have=20 > access to the full stream, in many cases "write access" so=20 > that they can munge various header fields about. >=20 > -- > Dean >=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=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 Mar 16 05:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJpt7-0006z8-Qk; Thu, 16 Mar 2006 05:39:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJekq-00046Z-60 for sip@ietf.org; Wed, 15 Mar 2006 17:46:08 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJekn-0002OT-RP for sip@ietf.org; Wed, 15 Mar 2006 17:46:08 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2FMk2l13807; Wed, 15 Mar 2006 17:46:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 16:45:48 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E0446@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIgUvJ6hYGPKNjTK6zPb3KZiDWAAAADSNw From: "Brian Stucker" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Thu, 16 Mar 2006 05:39:24 -0500 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 see where this is headed... Deprecation of forking. :) Seriously though, I don't think we can sit back and just say that this = is a badly designed service. These are real services that exist in the = real world that we all have to design and architect for in the near = term. Are you pushing for an RFC-2543 type revolution versus RFC-3261? We also have many esteemed colleagues in 3GPP and 3GPP2 (amongst other = groups) as you well know that allow and rely on deep packet inspection = (like the P-CSCF and S-CSCF) with all sorts of service and routing = interactions to boot. It seemed like in your earlier reply that you were = suggesting that if a SIP proxy didn't change anything in the message = other than the request URI and did it more than once that it should be a = BBUA. Did I read you correctly? Regards, Brian -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, March 15, 2006 4:39 PM To: Stucker, Brian [RICH1:B620:EXCH] Cc: Michael Hammer (mhammer); Cullen Jennings (fluffy); sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat (pkyzivat) Subject: Re: [Sip] The Problem with PRACK On Mar 15, 2006, at 11:38 AM, Brian Stucker wrote: > I don't know that I follow you suggestion in the specific case I am =20 > talking about. > > Take for instance Call Forward No Answer. In this case, A never =20 > says that it's done with the call before it is retargeted to B by =20 > the network. A and B have no idea that the service even exists in =20 > the middle. That's called a "badly designed service", from a security =20 perspective. If the service can squat on the call, whats to prevent =20 some other MITM? -- 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 Mar 16 05:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJpt6-0006yZ-U4; Thu, 16 Mar 2006 05:39:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZxD-000348-L7 for sip@ietf.org; Wed, 15 Mar 2006 12:38:35 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJZxD-0000Xl-8d for sip@ietf.org; Wed, 15 Mar 2006 12:38:35 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2FHcVl03943; Wed, 15 Mar 2006 12:38:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 11:38:27 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710D67E9A1@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZHOHchwiZepEnEQKyOIw4lVBiYVQATjQNAAC2+QQAAAvjd0A== From: "Brian Stucker" To: "Michael Hammer \(mhammer\)" , "Dean Willis" , "Cullen Jennings \(fluffy\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 X-Mailman-Approved-At: Thu, 16 Mar 2006 05:39:24 -0500 Cc: sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 that I follow you suggestion in the specific case I am = talking about. Take for instance Call Forward No Answer. In this case, A never says = that it's done with the call before it is retargeted to B by the = network. A and B have no idea that the service even exists in the = middle. Regards, Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Wednesday, March 15, 2006 8:42 AM To: Stucker, Brian [RICH1:B620:EXCH]; Dean Willis; Cullen Jennings (fluffy) Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat (pkyzivat) Subject: RE: [Sip] The Problem with PRACK =20 > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com]=20 > Sent: Tuesday, March 14, 2006 11:55 AM > To: Dean Willis; Cullen Jennings (fluffy) > Cc: sip@ietf.org; Francois Audet; Paul Kyzivat (pkyzivat) > Subject: RE: [Sip] The Problem with PRACK >=20 > Based on your proposals below, cryptographically transparent=20 > versus redirection: >=20 > How would you go about addressing applications like CPL that=20 > need to run timers for service logic and thus need to have=20 > some level of control over the session (not necessarily=20 > what's in the body of the messages, just where they're going)=20 > if a redirection model is used? >=20 > For example, without mucking about with what's inside the=20 > request, triggering off of the request URI of an INVITE to=20 > forward to destination A for X seconds and then to=20 > destination B. In this example the next hop changes over time=20 > for the same request and does not seem possible using=20 > redirection. This seems to preclude redirection as a general=20 > solution and drive towards requiring a proxy to be=20 > cryptographically transparent. Is there a reason the redirect server couldn't send you to A,=20 which then redirects or Refers you to B when A is done with=20 it's part of the service? It seems the proxy is best at directing traffic, while the UAS could contain distributed feature logic. Think of an assembly line of robots, each which knows its part of the process, but=20 not necessarily the whole. Mike >=20 > If the proxy is transparent, then how do you go about not=20 > precluding deep-packet inspection issues raised by=20 > applications such as QoS enforcement, network enforced=20 > identity or other services? It seems to me that HTTPS may=20 > make a bad model in that I'm unaware of any HTTPS-based=20 > application that has a box in the middle that needs to=20 > inspect and enforce certain characteristics of the request=20 > before it is handled by the final consumer of that request. >=20 > This seems to preclude cryptographic transparency as a=20 > general solution.=20 >=20 > I'm sure either can be used effectively in many application=20 > spaces, but it does not seem that either can be used as a=20 > general solution in the protocol itself. >=20 > Regards, > Brian >=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, March 14, 2006 1:08 AM > To: Cullen Jennings > Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul H Kyzivat > Subject: Re: [Sip] The Problem with PRACK >=20 >=20 >=20 > On Mar 14, 2006, at 12:24 AM, Cullen Jennings wrote: >=20 > > On 3/13/06 10:27 AM, "Dean Willis"=20 > wrote: > > > >> Right. But, SIPS is only required as far as the proxy serving the=20 > >> AOR. The AOR to Contact vector could be UDP/IPSEC, or even=20 > just plain=20 > >> unsecured UDP. > > > > I think we have a gathering amount of evidence that we want=20 > to update=20 > > this regardless of UDP or PRACK. >=20 >=20 > It's true that SIP proxies just don't work "right" with SIPS as it is. >=20 > When people first look at the "SIPS is only valid to the=20 > serving proxy" model they assume that simply changing the=20 > requirement to say that the proxy-to-UA leg must also be SIPS=20 > protected would provide a satisfactory answer. It doesn't,=20 > and this requires some careful thinking. >=20 > What security do you mandate on the serving-proxy to UA link? TLS? =20 > TLS supports many different ciphersuites. What keeps the=20 > crypto on the SP-UA link from being watered-down? Would other=20 > protections like IPSEC suffice? How would you end-to-end=20 > negotiate the cryptography so that the originating UA could=20 > believe that the entire chain was protected to some minimal=20 > level? And how do you offer some level of security to an IMS=20 > fashion-victim who is always going to be exposed to MITM=20 > attacks from his own service provider by design? >=20 > Personally, I think the only way SIPS really gives us the=20 > level of protection we have come to expect from HTTPS is if=20 > it is used end-to- end, either by abandoning proxy-routing in=20 > favor of a redirect model, or by causing the proxies to be=20 > cryptographically transparent as is done with HTTPS proxies. >=20 > This is an important thing to note: HTTPS proxies do NOT "see=20 > inside" =20 > the HTTPS stream. All they do is pass it along, unchanged, to=20 > the next hop. It could actually be some other protocol than=20 > HTTP, and they don't care and can't tell. To-date, we haven't=20 > treated SIPS proxies that way, and instead presume they have=20 > access to the full stream, in many cases "write access" so=20 > that they can munge various header fields about. >=20 > -- > Dean >=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=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 Mar 16 05:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJpt7-0006z8-Qk; Thu, 16 Mar 2006 05:39:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJekq-00046Z-60 for sip@ietf.org; Wed, 15 Mar 2006 17:46:08 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJekn-0002OT-RP for sip@ietf.org; Wed, 15 Mar 2006 17:46:08 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2FMk2l13807; Wed, 15 Mar 2006 17:46:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Wed, 15 Mar 2006 16:45:48 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E0446@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIgUvJ6hYGPKNjTK6zPb3KZiDWAAAADSNw From: "Brian Stucker" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Thu, 16 Mar 2006 05:39:24 -0500 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 see where this is headed... Deprecation of forking. :) Seriously though, I don't think we can sit back and just say that this = is a badly designed service. These are real services that exist in the = real world that we all have to design and architect for in the near = term. Are you pushing for an RFC-2543 type revolution versus RFC-3261? We also have many esteemed colleagues in 3GPP and 3GPP2 (amongst other = groups) as you well know that allow and rely on deep packet inspection = (like the P-CSCF and S-CSCF) with all sorts of service and routing = interactions to boot. It seemed like in your earlier reply that you were = suggesting that if a SIP proxy didn't change anything in the message = other than the request URI and did it more than once that it should be a = BBUA. Did I read you correctly? Regards, Brian -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, March 15, 2006 4:39 PM To: Stucker, Brian [RICH1:B620:EXCH] Cc: Michael Hammer (mhammer); Cullen Jennings (fluffy); sip@ietf.org; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat (pkyzivat) Subject: Re: [Sip] The Problem with PRACK On Mar 15, 2006, at 11:38 AM, Brian Stucker wrote: > I don't know that I follow you suggestion in the specific case I am =20 > talking about. > > Take for instance Call Forward No Answer. In this case, A never =20 > says that it's done with the call before it is retargeted to B by =20 > the network. A and B have no idea that the service even exists in =20 > the middle. That's called a "badly designed service", from a security =20 perspective. If the service can squat on the call, whats to prevent =20 some other MITM? -- 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 Mar 16 05:52:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJq46-00024i-3O; Thu, 16 Mar 2006 05:50:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJq44-00024H-GC for sip@ietf.org; Thu, 16 Mar 2006 05:50:44 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJq44-00050V-62 for sip@ietf.org; Thu, 16 Mar 2006 05:50:44 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 7631B140418; Thu, 16 Mar 2006 12:50:43 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 0C0F7140415; Thu, 16 Mar 2006 12:50:28 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id EDF6EF027F; Thu, 16 Mar 2006 12:50:56 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17433.17168.930320.463687@rautu.tutpro.com> Date: Thu, 16 Mar 2006 12:50:56 +0200 From: Juha Heinanen To: "Drage, Keith (Keith)" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <475FF955A05DD411980D00508B6D5FB0124F94D5@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0124F94D5@en0033exch001u.uk.lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sip@ietf.org, pkyzivat@cisco.com, christer.holmberg@ericsson.com, princeap@gmail.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 Drage, Keith (Keith) writes: > I'm afraid you cannot just deprecate part of the SIP 2.0 protocol. what is SIP 2.0 protocol? RFC3261 that most implementations today try to comply with, doesn't include PRACK. -- 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 Thu Mar 16 05:55:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJq6n-0002cI-O5; Thu, 16 Mar 2006 05:53:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJq6m-0002c2-1R for sip@ietf.org; Thu, 16 Mar 2006 05:53:32 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJq6l-00058j-NT for sip@ietf.org; Thu, 16 Mar 2006 05:53:32 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 1B289140418; Thu, 16 Mar 2006 12:53:31 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id BD1EE140415; Thu, 16 Mar 2006 12:53:25 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 5D0C8F027F; Thu, 16 Mar 2006 12:53:44 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17433.17336.337221.98027@rautu.tutpro.com> Date: Thu, 16 Mar 2006 12:53:44 +0200 From: Juha Heinanen To: "Brian Stucker" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E0446@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E0446@zrc2hxm2.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Francois Audet , "Paul Kyzivat \(pkyzivat\)" , 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 Brian Stucker writes: > I can see where this is headed... Deprecation of forking. :) go ahead and you have nothing else left that mimic of PSTN over IP. is that all what SIP was going to be? -- 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 Thu Mar 16 08:12:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsF9-0000qW-VF; Thu, 16 Mar 2006 08:10:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsF7-0000qM-U1 for sip@ietf.org; Thu, 16 Mar 2006 08:10:17 -0500 Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJsF6-0000ww-CZ for sip@ietf.org; Thu, 16 Mar 2006 08:10:17 -0500 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.36 ; Thu, 16 Mar 2006 14:10:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK - offerless invite Date: Thu, 16 Mar 2006 14:10:13 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK - offerless invite Thread-Index: AcZIiOdCzlFqOyMoSI+Gz3/zijKe6QAbn1rg From: "Christian Jansson" To: "Paul Kyzivat" , "Juha Heinanen" X-Spam-Score: 1.5 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" , Dean Willis , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >Consider Alice sends offerless invite to Bob. But Bob is only willing to >do secure calls. So Bob returns an offer in a 183 with security >preconditions. Bob needs an answer back that releases those >preconditions before he is willing to ring, much less answer. What does an offerless invite mean? In practice in the implementations that exist I guess that Bob will send back an offer for a single audio stream. But how can Bob know that? Why does Bob not include audio + video + application/whiteboard, etc, etc, and even worse, start all those apps in receiving mode as Bob now has generated the SDP offer? Probably Alice/Alice's UA would be very confused after receiving such a major SDP offer, given that most UAs of some reason expect an offerless invite to setup an "audio call". Have I missed something? (In that case flame me) Is it possible to build a 3pcc service that sets up a video+voice call using this offerless technique? / Christian Jansson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 08:13:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsGz-0001gz-5W; Thu, 16 Mar 2006 08:12:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsGy-0001ga-5y for sip@ietf.org; Thu, 16 Mar 2006 08:12:12 -0500 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 1FJsGw-00011X-R9 for sip@ietf.org; Thu, 16 Mar 2006 08:12:12 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 16 Mar 2006 05:12:10 -0800 X-IronPort-AV: i="4.02,197,1139212800"; d="scan'208"; a="416416300:sNHT26350776" 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 k2GDCAw1020376; Thu, 16 Mar 2006 05:12:10 -0800 (PST) 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.211); Thu, 16 Mar 2006 05:12:07 -0800 Received: from [10.21.90.12] ([10.21.90.12]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 05:12:09 -0800 Message-ID: <44196428.6080800@cisco.com> Date: Thu, 16 Mar 2006 08:12:08 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] The Problem with PRACK References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <17432.61795.685205.596416@rautu.tutpro.com> <17433.16194.547665.704204@rautu.tutpro.com> In-Reply-To: <17433.16194.547665.704204@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2006 13:12:09.0620 (UTC) FILETIME=[3B573540:01C648FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 Heinanen wrote: > Dean Willis writes: > > > Well, we meet the preconditions at ALL the forked-to endpoints before > > Bob answers. > > i didn't ask about answering, but when does bob's phone start to ring? > when it has got first 180 with accepted preconditions? I think we are all getting confused here. Alice called Bob, so Bob won't ever get a 180. Bob's phone will start to ring when all preconditions for both alice and bob have been satisfied. At that same time Bob will send a 180 to Alice, and Alice will begin to hear ringback. Paul > > sip-identity? > > yes, i was thinking of some IETF spec that lets the callee to verify using > PKI who is calling. perhaps such beast doesn't exist. > > > That might work too - a new 4xx message that returns a key to be used > > later. Hmm. > > your 3xx idea was better. > > -- 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 Thu Mar 16 08:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsK9-0002Nf-2j; Thu, 16 Mar 2006 08:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsK7-0002NY-Vx for sip@ietf.org; Thu, 16 Mar 2006 08:15:27 -0500 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 1FJsK6-00016t-Nu for sip@ietf.org; Thu, 16 Mar 2006 08:15:27 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2006 05:15:26 -0800 X-IronPort-AV: i="4.02,197,1139212800"; d="scan'208"; a="314909890:sNHT25397478" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2GDFPGv029427; Thu, 16 Mar 2006 05:15:25 -0800 (PST) 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.211); Thu, 16 Mar 2006 05:15:25 -0800 Received: from [10.21.90.12] ([10.21.90.12]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 05:15:25 -0800 Message-ID: <441964EC.7080203@cisco.com> Date: Thu, 16 Mar 2006 08:15:24 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] The Problem with PRACK References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <17432.61795.685205.596416@rautu.tutpro.com> <441906A9.2090802@cisco.com> <45C84134-9B75-4E45-AF67-F281607DBF6E@softarmor.com> In-Reply-To: <45C84134-9B75-4E45-AF67-F281607DBF6E@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2006 13:15:25.0324 (UTC) FILETIME=[AFFD44C0:01C648FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, Juha Heinanen , "Christer Holmberg \(JO/LMF\)" , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > > On Mar 16, 2006, at 12:33 AM, Paul Kyzivat wrote: > > >> >>> what comes to your example, why can't bob return back a 4xx response >>> with security preconditions, the same way authentication works? >> >> HERFP. > > No, not if we could match the 4x to a contact-specific target for the > followon request. Huh? In presence of forking this doesn't help. You can only return one 4xx response. 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 Mar 16 08:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsVb-0003hG-Mt; Thu, 16 Mar 2006 08:27:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsVa-0003hB-15 for sip@ietf.org; Thu, 16 Mar 2006 08:27:18 -0500 Received: from reloaded.ext.ti.com ([192.94.94.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJsVZ-0001Sj-HF for sip@ietf.org; Thu, 16 Mar 2006 08:27:17 -0500 Received: from dlep30.itg.ti.com ([157.170.170.32]) by reloaded.ext.ti.com (8.13.4/8.13.4) with ESMTP id k2GDR6Bq004664 for ; Thu, 16 Mar 2006 07:27:15 -0600 (CST) Received: from dlep90.itg.ti.com (localhost [127.0.0.1]) by dlep30.itg.ti.com (8.12.11/8.12.11) with ESMTP id k2GDR2W6012940 for ; Thu, 16 Mar 2006 07:27:02 -0600 (CST) Received: from dlee71.ent.ti.com (localhost [127.0.0.1]) by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id k2GDR28Z016250 for ; Thu, 16 Mar 2006 07:27:02 -0600 (CST) Received: from dlee06.ent.ti.com ([157.170.170.73]) by dlee71.ent.ti.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 16 Mar 2006 07:27:01 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Mar 2006 07:27:00 -0600 Message-ID: <6A960E377BE21549A178517AB49B00A7032A42D2@dlee06.ent.ti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [query] service level capabilities spefifications between different SIP entities Thread-Index: AcZF7o7XYEKZujjjRQeHsOFNQJi+2QDDXDHw From: "Khare, Anir" To: X-OriginalArrivalTime: 16 Mar 2006 13:27:01.0903 (UTC) FILETIME=[4F2EC9F0:01C648FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Subject: [Sip] [query] service level capabilities spefifications between different SIP entities X-BeenThere: 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="===============1782110810==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1782110810== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C648FD.4F173234" This is a multi-part message in MIME format. ------_=_NextPart_001_01C648FD.4F173234 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3261 provides mechanisms to advertise capabilities between the interacting SIP entities. E.g. SIP header fields like require etc. The capabilities exchanged are essentially related to SIP level artifacts e.g. a particular SIP method supported or a particular SIP extensions specified in RFCs supported. However there are no mechanisms available to specify capabilities related to distributed services which use SIP as signaling mechanism to coordinate between different services entities. Hence these SIP entities do not necessarily interoperate even if all of them strictly comply to SIP standards for transporting service interactions. Some standard call flows and best practices are specified in RFCs, however there are no standard ways of specifying service level capabilities of a SIP entity and the associated call flows that it can support.=20 =20 SDP focuses on end point to end point negotiation of some service attributes, however there is no semantics anticipated related to capabilities negotiation with intermediaries. RFC 3959/3960 suggests some mechanisms during "early media" phase of the session. =20 SIP is rendezvous protocol, this means existence of intermediaries is central part of the architecture (in peer to peer SIP the definition of intermediaries is slightly diluted). Intermediaries are essentially envisaged for finding the end points and routing communication between them. RFC3840 suggests that end points can externalize some information (during registration time) in order to influence this routing. =20 In non- peer to peer models, SIP proxies provide more than the basic rendezvous functions and it may be useful to have some unified mechanism for service level negotiations between end points and intermediaries or between intermediaries.=20 =20 =20 If this is available then a given SIP end point will be able to dynamically participate in different service environments, by dynamically recognizing call flows/capabilities in a particular service environment.=20 =20 Are there any existing mechanisms specified in any RFCs which can deal with these issues. If not, will addition of those be inline with the overall SIP architecture? =20 Standardization of call flows across all service environments could be another alternative way to look at this; however it will lot difficult to realize and may not be inline with the spirit of SIP as an open signaling protocol. =20 Any clarifications, suggestions on this topic are appreciated. =20 Thanks, Anir Khare =20 ------_=_NextPart_001_01C648FD.4F173234 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3261 provides mechanisms to advertise capabilities = between the = interacting SIP entities. E.g. SIP header fields like require etc. The capabilities = exchanged are essentially related to SIP level artifacts e.g. a particular SIP = method supported or a particular SIP extensions specified in RFCs supported. = However there are no mechanisms available to specify capabilities related to distributed services which use SIP as signaling mechanism to coordinate = between different services entities. Hence these SIP entities do not necessarily interoperate even if all of them strictly comply to SIP standards for transporting service interactions. Some standard call flows and best = practices are specified in RFCs, however there are no standard ways of specifying = service level capabilities of a SIP entity and the associated call flows that it = can support.

 

SDP focuses on end point to end point negotiation of = some service attributes, however there is no semantics anticipated related to capabilities negotiation with intermediaries. RFC 3959/3960 suggests some mechanisms during = “early media” phase of the = session.

 

SIP is rendezvous protocol, this means existence of intermediaries is central part of the architecture (in peer to peer SIP = the definition of intermediaries is slightly diluted). Intermediaries are essentially envisaged for finding the end points and routing = communication between them. RFC3840 suggests that end points can externalize some = information (during registration time) = in order to influence this routing.

 

In non- peer to peer models, SIP proxies provide more = than the basic rendezvous functions and it may be useful to have some unified mechanism for service level = negotiations between end points and intermediaries or between intermediaries. =

 

 

If this is available then = a given SIP end point will be able to = dynamically participate in different service environments, by dynamically recognizing call flows/capabilities in a particular service environment. =

 

Are there any existing mechanisms specified in any = RFCs which can deal with these issues. If not, will addition of those be = inline with the overall SIP architecture?

 

Standardization of call flows across all service environments could = be another alternative way to = look at this; however it will lot difficult to realize and may not be inline with the = spirit of SIP as an open signaling protocol.

 

Any clarifications, suggestions on = this topic are appreciated.

 

Thanks,

=

Anir Khare

 

------_=_NextPart_001_01C648FD.4F173234-- --===============1782110810== 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 --===============1782110810==-- From sip-bounces@ietf.org Thu Mar 16 08:31:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsY1-0005JS-Fb; Thu, 16 Mar 2006 08:29:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsY0-0005JN-8z for sip@ietf.org; Thu, 16 Mar 2006 08:29:48 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJsXy-0001YN-U1 for sip@ietf.org; Thu, 16 Mar 2006 08:29:48 -0500 Received: by tutpro.com (Postfix, from userid 65534) id AC5A0140415; Thu, 16 Mar 2006 15:29:45 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 1318814040A; Thu, 16 Mar 2006 15:29:40 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id D67D4F027F; Thu, 16 Mar 2006 15:30:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17433.26719.823233.167864@rautu.tutpro.com> Date: Thu, 16 Mar 2006 15:30:07 +0200 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <44196428.6080800@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <17432.61795.685205.596416@rautu.tutpro.com> <17433.16194.547665.704204@rautu.tutpro.com> <44196428.6080800@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 writes: > I think we are all getting confused here. Alice called Bob, so Bob won't > ever get a 180. Bob's phone will start to ring when all preconditions > for both alice and bob have been satisfied. At that same time Bob will > send a 180 to Alice, and Alice will begin to hear ringback. what about if he call gets forked to another plain old RFC3261 UA that replies with 200 OK after 180 has come from Bob to Alice? -- 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 Thu Mar 16 08:32:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsZH-0006PT-Jm; Thu, 16 Mar 2006 08:31:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsZG-0006PO-DP for sip@ietf.org; Thu, 16 Mar 2006 08:31:06 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJsZG-0001ag-2o for sip@ietf.org; Thu, 16 Mar 2006 08:31:06 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 7E6D4140415; Thu, 16 Mar 2006 15:31:05 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 6A55E14040A; Thu, 16 Mar 2006 15:30:50 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id E3D76F027F; Thu, 16 Mar 2006 15:31:18 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17433.26790.878129.156055@rautu.tutpro.com> Date: Thu, 16 Mar 2006 15:31:18 +0200 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <441964EC.7080203@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <17432.61795.685205.596416@rautu.tutpro.com> <441906A9.2090802@cisco.com> <45C84134-9B75-4E45-AF67-F281607DBF6E@softarmor.com> <441964EC.7080203@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 writes: > Huh? In presence of forking this doesn't help. You can only return one > 4xx response. that is why i said that Dean's 3xx idea was a better one, because proxy is supposed to collect all 3xx replies to its reply to the caller. -- 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 Thu Mar 16 08:51:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsqn-0004Lh-SY; Thu, 16 Mar 2006 08:49:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsqn-0004Lc-CN for sip@ietf.org; Thu, 16 Mar 2006 08:49:13 -0500 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 1FJsqn-000293-3n for sip@ietf.org; Thu, 16 Mar 2006 08:49:13 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 16 Mar 2006 05:49:12 -0800 X-IronPort-AV: i="4.02,197,1139212800"; d="scan'208"; a="416425749:sNHT25518624" 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 k2GDnCGv016552; Thu, 16 Mar 2006 05:49:12 -0800 (PST) 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.211); Thu, 16 Mar 2006 05:49:09 -0800 Received: from [10.21.90.12] ([10.21.90.12]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 05:49:11 -0800 Message-ID: <44196CD6.2010707@cisco.com> Date: Thu, 16 Mar 2006 08:49:10 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] The Problem with PRACK References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <54FCC73F-0A54-4EE8-B3C9-27C8C0D1E612@softarmor.com> <17432.62006.483903.565365@rautu.tutpro.com> <44190887.9030705@cisco.com> <17433.15806.520993.376972@rautu.tutpro.com> In-Reply-To: <17433.15806.520993.376972@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2006 13:49:11.0724 (UTC) FILETIME=[67D15EC0:01C64900] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 Heinanen wrote: > Paul Kyzivat writes: > > > Well, I'm pretty sure PRACK was created before SUBSCRIBE. Does that mean > > that we should trash SUBSCRIBE too? > > if you could have implemented same functionality with existing SIP > requests, which is not likely with subscribe, but is likely with PRACK. I guess then that the entire WG was really very stupid to have approved RFC3262. > > Nobody has come up with a case where PRACK can't be replaced by some > > other vaguely specified hypothetical new extension to sip. That isn't a > > fair comparison. > > you can dump PRACK for resource reservation without ANY extension to SIP > as i have shown in earlier messages. it was 3gpp folks that defended > PRACK on the basis of resource reservation, and they claims turned out > to be false. I am not trying to defend the 3gpp people. But you haven't proven that their claims are false. You have shown that with a particular set of simplifying assumptions about the problem space you can do without PRACK. I think there must be a higher bar for deprecating an RFC. I now understand that Rohan is advocating something much less than that. Even that needs good justification, but might be easier to achieve. Paul > > So we are stuck for now with evolutionary changes. Incompatible changes > > are hard to do. > > evolution in should also mean deprecating bad ideas, not all the time > adding new RFCs to the pile. > > -- 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 Thu Mar 16 08:58:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsxn-0005jq-N3; Thu, 16 Mar 2006 08:56:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsxm-0005jl-8n for sip@ietf.org; Thu, 16 Mar 2006 08:56:26 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJsxk-0002WS-Ur for sip@ietf.org; Thu, 16 Mar 2006 08:56:26 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IW8004013XDDK@siemenscomms.co.uk> for sip@ietf.org; Thu, 16 Mar 2006 13:53:38 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IW80038J3XDBN@siemenscomms.co.uk>; Thu, 16 Mar 2006 13:53:37 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Mar 2006 13:56:23 +0000 Content-return: allowed Date: Thu, 16 Mar 2006 13:56:10 +0000 From: "Elwell, John" Subject: RE: [Sip] The Problem with PRACK To: Paul Kyzivat , Juha Heinanen Message-id: <50B1CBA96870A34799A506B2313F266708655EB3@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" , Dean Willis , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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, You wrote: > Consider Alice sends offerless invite to Bob. But Bob is only > willing to > do secure calls. So Bob returns an offer in a 183 with security > preconditions. Bob needs an answer back that releases those > preconditions before he is willing to ring, much less answer. I don't think preconditions brings anything to this at all. Bob's UA could wait for the SDP answer from Alice's UA before starting to ring Bob without any need to perform preconditions. However, the security precondition does appear to have a use with security. Suppose Alice's UA sends an offer in an INVITE request to Bob's UA. Bob's UA starts to ring Bob and, on answer, sends back an answer in the 200. If the offer requested SRTP and Alice's UA needs the answer before being able to decrypt the SRTP, then arrival in the 200 is a bit too late to prevent speech clipping. Arrival in a 180 would help, but not if Bob's UA auto-answers (sends 200 without first sending 180 or sends 200 immediately after 180). This is where the security precondition can help, by postponing the ringing of Bob until Alice's UA receives the SDP answer and the means to decrypt SRTP. 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 Thu Mar 16 09:15:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtEF-0004d3-LP; Thu, 16 Mar 2006 09:13:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtEE-0004cy-NB for sip@ietf.org; Thu, 16 Mar 2006 09:13:26 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJtED-0003KV-7I for sip@ietf.org; Thu, 16 Mar 2006 09:13:26 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 16 Mar 2006 06:13:24 -0800 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 k2GEDOGv000800; Thu, 16 Mar 2006 06:13:24 -0800 (PST) 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.211); Thu, 16 Mar 2006 06:13:21 -0800 Received: from [10.21.90.12] ([10.21.90.12]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 06:13:23 -0800 Message-ID: <4419727F.4070107@cisco.com> Date: Thu, 16 Mar 2006 09:13:19 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Jansson Subject: Re: [Sip] The Problem with PRACK - offerless invite References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2006 14:13:24.0005 (UTC) FILETIME=[C971DD50:01C64903] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, Juha Heinanen , "Christer Holmberg \(JO/LMF\)" , Dean Willis , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christian Jansson wrote: >>Consider Alice sends offerless invite to Bob. But Bob is only willing > > to > >>do secure calls. So Bob returns an offer in a 183 with security >>preconditions. Bob needs an answer back that releases those >>preconditions before he is willing to ring, much less answer. > > > What does an offerless invite mean? In practice in the implementations > that exist I guess that Bob will send back an offer for a single audio > stream. I certainly hope the reason you see this as the common practice is because the majority of UAs only support audio. There is certainly no implied bias towards audio in the offerless invite. I expect that a UA should offer that which has the capability to do, and that it thinks are appropriate to offer according to its *own* current state and context. Ideally in a UA with the capability for more than one type of media, the ones to use in this manner would be configurable. (E.g. whether to offer video as well as audio.) > But how can Bob know that? Why does Bob not include audio + > video + application/whiteboard, etc, etc, and even worse, start all > those apps in receiving mode as Bob now has generated the SDP offer? Depending on the capabilities of the UA, it may well want to do all of that. > Probably Alice/Alice's UA would be very confused after receiving such a > major SDP offer, given that most UAs of some reason expect an offerless > invite to setup an "audio call". If they do, then they ought to do more thinking about the future. This is no different than receiving an invite offering many media. > Have I missed something? (In that case flame me) > > Is it possible to build a 3pcc service that sets up a video+voice call > using this offerless technique? Certainly it is possible. In spite of the latent capabilities, actual usage of sip for multimedia applications seems very limited. As this becomes more common these issues will come into view. I consider this an area that needs a lot of attention if it is to work in a reasonable way. There are many possibilities for interoperability problems. For instance I get the impression that some people think that multimedia means establishing a separate sip dialog for each medium and then correlating those dialogs. Such an approach won't interoperate well with one that includes multiple media sessions in a single sip dialog. 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 Mar 16 10:02:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtxi-0002v0-QF; Thu, 16 Mar 2006 10:00:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtxh-0002uv-N5 for sip@ietf.org; Thu, 16 Mar 2006 10:00:25 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJtxg-0004RC-FL for sip@ietf.org; Thu, 16 Mar 2006 10:00:25 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k2GF0IcN083310; Thu, 16 Mar 2006 10:00:22 -0500 (EST) From: "Brett Tate" To: "'Rohan Mahy'" , "'Jonathan Rosenberg'" Subject: RE: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 10:01:23 -0500 Message-ID: <001b01c6490a$7e450170$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <953beacc0603151846i57f6d3fdm4970043b8e3b9991@mail.gmail.com> Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 went back over the 102 messages in this thread and=20 > did not hear any comments on my concrete proposals: >=20 > - require RSeq to start at 1 I do not understand how this really helps. The queuing at UAS because = of offer/answer rules (and ensuring dialog established) is still required. = And if I recall correctly, UPDATEs are now required instead of sending a new offer within INVITE 18x/2xx.=20 Are you wanting the UAC to queue out-of-order 18x's? > - only acknowledge the most recent provisional.=20 > if the UAS wants to send as new provisional that=20 > completely replaces a previous one it can send=20 > immediately. if the UAS wants to send a new=20 > provisional but wants acknowledgement of a previous=20 > one, it has to wait for the PRACK. I assume RSeq would still be checked so UAC is able to notice out of = order provisional responses. It looks like this would impact the current offer/answer rules. Are you suggesting changes related to offer/answer within first 18x and/or subsequent 18x's? > - send a provisional every 1 minute whether reliable=20 > or not. (instead of every one minute for unreliable=20 > and every 2.5 minutes for reliable) I assume this is to better deal with a mixture of reliable and = unreliable transports. The idea sounds fine. However if 100rel is used, I do not = see a reason to reduce the interval. Did you want Timer C reduced also? > - deprecate *offers* in PRACK (answers are still OK) Sounds good to me. However leaving it is ok if vendors who send it can = deal with the typical interop problems such as receiving PRACK 200 without an answer indicating the PRACK's offer was ignored. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 10:17:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuC2-0004wM-JS; Thu, 16 Mar 2006 10:15:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuC1-0004sT-Fk for sip@ietf.org; Thu, 16 Mar 2006 10:15:13 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJuC0-0004wT-8i for sip@ietf.org; Thu, 16 Mar 2006 10:15:13 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2GFF0HJ001624; Thu, 16 Mar 2006 09:15:00 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Mar 2006 15:14:59 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0124F959A@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Juha Heinanen , "Drage, Keith (Keith)" Subject: RE: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 15:14:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, pkyzivat@cisco.com, christer.holmberg@ericsson.com, princeap@gmail.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 SIP 2.0 is every active RFC that currently exists for SIP. For an overview, see Jonathan's hitchhiker's guide document. When we produce an RFC that starts messages with SIP 3.0, then we go to a new version. Until we do that any extension has to be compatible with all other extensions. regards Keith > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: 16 March 2006 10:51 > To: Drage, Keith (Keith) > Cc: Erkki.Koivusalo@nokia.com; sip@ietf.org; pkyzivat@cisco.com; > princeap@gmail.com; christer.holmberg@ericsson.com > Subject: RE: [Sip] The Problem with PRACK > > > Drage, Keith (Keith) writes: > > > I'm afraid you cannot just deprecate part of the SIP 2.0 protocol. > > what is SIP 2.0 protocol? RFC3261 that most implementations today try > to comply with, doesn't include PRACK. > > -- 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 Thu Mar 16 11:15:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJv6g-0002GH-Sn; Thu, 16 Mar 2006 11:13:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJv6e-0002GC-Vy for sip@ietf.org; Thu, 16 Mar 2006 11:13:44 -0500 Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJv6e-0007BH-E5 for sip@ietf.org; Thu, 16 Mar 2006 11:13:44 -0500 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.36 ; Thu, 16 Mar 2006 17:13:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK - offerless invite Date: Thu, 16 Mar 2006 17:13:42 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK - offerless invite Thread-Index: AcZJBS7fhjcXbCgzRrWpDbO94KTargACoWNg From: "Christian Jansson" To: "Paul Kyzivat" X-Spam-Score: 1.5 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org, Juha Heinanen , "Christer Holmberg \(JO/LMF\)" , Dean Willis , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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 is certainly no implied bias towards audio in the offerless >invite. I expect that a UA should offer that which has the capability to >do, and that it thinks are appropriate to offer according to its *own* >current state and context. Ideally in a UA with the capability for more >than one type of media, the ones to use in this manner would be >configurable. (E.g. whether to offer video as well as audio.) > >> But how can Bob know that? Why does Bob not include audio + >> video + application/whiteboard, etc, etc, and even worse, start all >> those apps in receiving mode as Bob now has generated the SDP offer? > >Depending on the capabilities of the UA, it may well want to do all of >that. So completely depending on Bob's UA, Alice may get _any_ kind of call back, msrp+audio, video+application/whiteboard, 2 video streams? Even though Alice initially invited Bob! Why would Alice invite Bob at all if she does not have _any_ clue of what session Bob will offer? Offerless invites are useless in practice for anything else than audio, that is a fact, and I have seen the problems when trying to get things to interoperate. >> Is it possible to build a 3pcc service that sets up a video+voice call >> using this offerless technique? > >Certainly it is possible. Possible, but not in a controllable way. It would be impossible for the 3pcc to indicate that it should be a video+voice call.=20 The only way to get this to work is to create a new extension to let offerless invites indicate the media that should be included in the session. But that would also mean that only new UAs that chose to support that extension would behave well in 3pcc scenarios. (I would say that the sane answer to "I invite you" would be "to what?", not to start guessing.) / Christian Jansson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 11:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJvFE-000447-3r; Thu, 16 Mar 2006 11:22:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJvFC-0003yU-Fq for sip@ietf.org; Thu, 16 Mar 2006 11:22:34 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJvF7-0007bj-UP for sip@ietf.org; Thu, 16 Mar 2006 11:22:34 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k2GGMLGL009671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Mar 2006 17:22:21 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k2GGMGuh025587; Thu, 16 Mar 2006 17:22:16 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k2GGMBO8025584; Thu, 16 Mar 2006 17:22:11 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] Re: draft-ietf-sip-outbound-02 From: Hans Persson To: Cullen Jennings In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Thu, 16 Mar 2006 17:22:10 +0100 Message-Id: <1142526130.11076.88.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Thu, 16 Mar 2006 17:22:21 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: "sip@ietf.org" , Paul H 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 I have some nits on outbound-02. Section 1, first paragraph: Remove the "the" starting line three. "Connection to the UA" -> "Connections to the UA". Section 1, last paragraph: "Since," -> "Since". "keep alive" -> "keep-alive" (this applies to lots of places throughout the text). Section 2.1. "flow" definition should be "Flow". Colon missing after outbound-proxy-set definition. Section 3: Add comma after "redundancy". Section 3.2, second paragraph: Add "which" after "reg-id parameter". Section 3.3, second paragraph: Shouldn't "two" on line two be "multiple" or something like that? The rest of the paragraph talks about "two of the physical hosts" and things like that, implying the presence of more than two. Another option is that the text should be something like "two logical hosts" to differentiate it from "physical hosts" later. Section 3.3, second paragraph: "the two connection" -> "the two connections". fourth paragraph: Move "approach" to before the parenthesis for better readability. Section 3.4: It seems to be the idea that "Edge Proxy" is to be capitalized, but starting here there are several instances where this is not the case. Section 3.5, Note: "detect a changes" -> "detect a changed", "per connection" -> "per-connection". Section 4.1, first paragraph: "cylces" -> "cycles". Section 4.2, first paragraph: Sentence two starts with "The" but it would be better with "This". Section 4.3.1: "When an UA" -> "When a UA". Section 4.3.2: "non TLS" -> "non-TLS". Remove comma after "to this IP address". The sentence starting with "For TLS protocols" should be taken out and shot. I *think* changing "in the next hop URI MUST match one" to "in the next hop URI matches one". Section 4.4, second paragraph: "UDP based" -> "UDP-based". "TCP based" - > "TCP-based". Note: Insert "make" before "the keep-alive" and "upper bound" after "120 seconds". Section 4.5, second paragraph: The base time is set to 90 seconds here, but in the next paragraph it is 60 seconds. Insert "the" before "power of the number". Section 5.2, Algorithm 1: Change "This results in an approximately 16 octet identifier." to "This results in an identifier approximately 16 octets long." Algorithm 2: "20 byte" -> "20-octet". "The concatenation of the HMAC and S are" -> "The concatenation of the HMAC and S is". "32 octet" -> "32- octet". Section 5.3, Algorithm 2: Remove the comma after "flow token" and put it after "URI". Insert "that" after "checking". Section 6.1, heading: "Register" -> "REGISTER". Third paragraph: Remove the first comma. Section 7, heading: "UAS" -> "UASs". First paragraph: "register" -> "REGISTER". Section 8, last-but-one paragraph: Remove duplicated and misspelled "seams". Section 10.1, first paragraph: Spurious space after reference. Section 10.2, first paragraph: Ditto. Section 10.3, Description: Change "A Registrar places this option-tag in a Supported header to communicate to the registering User Agent the Registrars support for this extension." to "A Registrar places this option-tag in a Supported header to communicate the Registrar's support for this extension to the registering User Agent." Section 11, third paragraph: "route" -> "Route". Fourth paragraph: "route header" -> "Route header". "path header" -> "Path header". Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 11:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJvhG-0005LV-QH; Thu, 16 Mar 2006 11:51:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJvhE-0005FW-NY for sip@ietf.org; Thu, 16 Mar 2006 11:51:32 -0500 Received: from web8903.mail.in.yahoo.com ([203.84.221.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJvhC-0008Pj-Kt for sip@ietf.org; Thu, 16 Mar 2006 11:51:32 -0500 Received: (qmail 322 invoked by uid 60001); 16 Mar 2006 16:51:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SbPS7oRhDqqm6hcwE3OgSSvW5WjJPIX9cCMl5cSlOfriTMUn3J54zC4w5HC8thbqtJenE8X0vUliOiaL5f2I3W9Hwg7vB/4VyQlQLs3D2iWPNWKuXTwvRWVXYo2RcOXEpIKi3e9lLSwoE5E2XC3pbrrngnxxsMzK8kCsQqxWDxs= ; Message-ID: <20060316165127.320.qmail@web8903.mail.in.yahoo.com> Received: from [210.214.40.84] by web8903.mail.in.yahoo.com via HTTP; Thu, 16 Mar 2006 16:51:27 GMT Date: Thu, 16 Mar 2006 16:51:27 +0000 (GMT) From: Thejeswara Reddy To: simple@ietf.org, sip ietf MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Sip] Simple and MBUS X-BeenThere: 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="===============1299306369==" Errors-To: sip-bounces@ietf.org --===============1299306369== Content-Type: multipart/alternative; boundary="0-935317296-1142527887=:96083" Content-Transfer-Encoding: 8bit --0-935317296-1142527887=:96083 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit HI, How about supporting MBUS IN SIP&SIMPLE. MBUS-->Message bus allows Device co-ordination. using SIMPLE can we extend it for interactive Session between Devices. thanks theja --------------------------------- Jiyo cricket on Yahoo! India cricket Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-935317296-1142527887=:96083 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit HI,
      How about supporting MBUS IN SIP&SIMPLE.

MBUS-->Message bus allows Device co-ordination.

using SIMPLE can we extend it for  interactive Session between Devices.

thanks
theja

Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-935317296-1142527887=:96083-- --===============1299306369== 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 --===============1299306369==-- From sip-bounces@ietf.org Thu Mar 16 12:44:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwUk-00031v-Ih; Thu, 16 Mar 2006 12:42:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwUj-00031h-Ex for sip@ietf.org; Thu, 16 Mar 2006 12:42:41 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJwUh-00024I-W8 for sip@ietf.org; Thu, 16 Mar 2006 12:42:41 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k2GHgcu10342 for ; Thu, 16 Mar 2006 18:42:38 +0100 (MET) Received: from heisenberg.fokus.fraunhofer.de ([10.147.9.232]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 18:39:51 +0100 Received: from [10.147.65.87] ([10.147.65.87]) by heisenberg.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 18:39:51 +0100 Message-ID: <4419A2E7.9050800@fokus.fraunhofer.de> Date: Thu, 16 Mar 2006 18:39:51 +0100 From: Sven Ehlert Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------050807020606020308000200" X-OriginalArrivalTime: 16 Mar 2006 17:39:51.0327 (UTC) FILETIME=[A0DD32F0:01C64920] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: [Sip] Third VoIP Security Workshop, Registration OPEN X-BeenThere: sip@ietf.org X-Mailman-Version: 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. --------------050807020606020308000200 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.fraunhofer.de id k2GHgcu10342 Third Annual VoIP Security Workshop In Cooperation with ACM SIGCOMM Berlin, Germany 01, 02 June 2006 www.iptel.org/voipsecurity Registration OPEN as of today! This security workshop is the third following successful events in Dallas 2004 and Washington 2005. The workshop addresses the challenges, advanced technologies and regulations for providing secure VoIP services in the Internet as well as in third generation networks. The 2006 workshop will extend the scope of VoIP security to IMS services and present the latest advances in denial of service and SPIT detection and protection mechanisms. The format of the workshop is based on two-day single-track sessions, with presentations of invited and regular papers from academia and industry. The papers solicited in the Third VoIP Security workshop cover a variety of topics including but not limited to: * Intrusion and anomaly detection of VoIP and IMS systems * SPIT/SPIM detection and prevention * Threat and vulnerability analyses of VoIP and IMS systems * Regulatory aspects of VoIP and IMS communication * Securing Peer-to-peer systems * Securing service creation environments * Privacy and anonymity * Monitoring and testing tools for VoIP and IMS infrastructures * Security of VoIP supporting systems such as AAA and ENUM * Support of lawful interception and securing emergency services in VoIP and IMS services * High availability solutions for VoIP and IMS systems The Third VoIP Security workshop is a two day workshop with a special session of invited papers from industry and government. The program committee will referee all papers, and accepted papers will be published in the conference proceedings General Chair: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Radu Popescu-Zeletin Fraunhofer Fokus Program Chairs: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dorgham Sisalem Tekelec Ram Dantu University of North Texas Henning Schulzrinne Columbia University Local Organization Chair: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sven Ehlert Fraunhofer Fokus Technical Program Committee =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ralf Ackermann TU Darmstadt Hossam Afifi INT Evry Elisa Bertino Purdue University George Carle T=FCbingen University Jasson Casey Alcatel Ram Dantu University of North Texas Sven Ehlert Fraunhofer Fokus Sonia Fahmy Purdue University Dipak Ghosal University of California Davis G=FCnter M=FCller University of Freiburg Saverio Niccolini NEC Labs Europe J=F6rg Ott Helsinki University of Technolo= gy Ozgur Gurleyen Vodafone Basavaraj Patil Nokia Neeli Rashmi Prasad University of Aalborg Pradeep Samudra Samsung Peter Schoo DoCoMo Euro-Labs Henning Schulzrinne Columbia University Dorgham Sisalem Tekelec Jeff Smith DHS Burkhard Stiller University of Zurich and ETH Zuri= ch Duminda Wijesekeara George Mason University --------------050807020606020308000200 Content-Type: text/x-vcard; charset=utf-8; name="ehlert.vcf" Content-Disposition: attachment; filename="ehlert.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Sven Ehlert n:Ehlert;Sven org:NGNI;Fraunhofer FOKUS adr:;;Kaiserin-Augusta-Allee 31;Berlin;;10589;Germany email;internet:ehlert@fokus.fraunhofer.de tel;work:+49-30-3463-7378 tel;fax:+49-30-3463-8000 url:http://www.fokus.fraunhofer.de version:2.1 end:vcard --------------050807020606020308000200 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 --------------050807020606020308000200-- From sip-bounces@ietf.org Thu Mar 16 13:10:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwuF-0002pw-F9; Thu, 16 Mar 2006 13:09:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwuE-0002pr-I2 for sip@ietf.org; Thu, 16 Mar 2006 13:09:02 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJwuE-0002nq-7B for sip@ietf.org; Thu, 16 Mar 2006 13:09:02 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2GI8rf5022671; Thu, 16 Mar 2006 12:08:53 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Mar 2006 18:08:52 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0124F9601@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Paul Kyzivat , Juha Heinanen Subject: RE: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 18:08:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" , Dean Willis , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Part of Juha's simplifications also assume that the charging models used by various 3gpp operator's are invalid. As IETF has not specified a charging model for SIP, or the resources under the control of SIP, and does not intend to, I would suggest that we have to assume there is no such restriction, and therefore have to make sure our protocol supports a multitude of charging cases. If we wish to start providing such restrictions, then I would suggest IETF needs to specify the charging model as a means of identifying those restrictions. However I do not think this is likely to occur. regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 16 March 2006 13:49 > To: Juha Heinanen > Cc: sip@ietf.org; Brett Tate; Christer Holmberg (JO/LMF); Dean Willis > Subject: Re: [Sip] The Problem with PRACK > > > > > Juha Heinanen wrote: > > Paul Kyzivat writes: > > > > > Well, I'm pretty sure PRACK was created before > SUBSCRIBE. Does that mean > > > that we should trash SUBSCRIBE too? > > > > if you could have implemented same functionality with existing SIP > > requests, which is not likely with subscribe, but is likely > with PRACK. > > I guess then that the entire WG was really very stupid to > have approved > RFC3262. > > > > Nobody has come up with a case where PRACK can't be > replaced by some > > > other vaguely specified hypothetical new extension to > sip. That isn't a > > > fair comparison. > > > > you can dump PRACK for resource reservation without ANY > extension to SIP > > as i have shown in earlier messages. it was 3gpp folks > that defended > > PRACK on the basis of resource reservation, and they claims > turned out > > to be false. > > I am not trying to defend the 3gpp people. But you haven't > proven that > their claims are false. You have shown that with a particular set of > simplifying assumptions about the problem space you can do > without PRACK. > > I think there must be a higher bar for deprecating an RFC. > > I now understand that Rohan is advocating something much less > than that. > Even that needs good justification, but might be easier to achieve. > > Paul > > > > So we are stuck for now with evolutionary changes. > Incompatible changes > > > are hard to do. > > > > evolution in should also mean deprecating bad ideas, not > all the time > > adding new RFCs to the pile. > > > > -- 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 Thu Mar 16 13:31:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxDj-0000SF-3u; Thu, 16 Mar 2006 13:29:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxDg-0000QT-Q9 for sip@ietf.org; Thu, 16 Mar 2006 13:29:08 -0500 Received: from pproxy.gmail.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJxDg-0003Ga-Ej for sip@ietf.org; Thu, 16 Mar 2006 13:29:08 -0500 Received: by pproxy.gmail.com with SMTP id n25so565474pyg for ; Thu, 16 Mar 2006 10:28:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=bAk/yRXrL4vC2OJoXD54KJ47nu3SYugCc772Dq6X2sCrkFb3IX1q+UUQoLxGFV9ebpG3Lnuew0k/iqvzx296s9OamU/8cN8VyDfePQIEnYQhzeyqTtsMjXe7YU3q/kVwnA6W0h5FjBIzxrH3W/c3FrB8pyae0aqoyUkVsJIFcYM= Received: by 10.35.49.4 with SMTP id b4mr1752260pyk; Thu, 16 Mar 2006 10:28:34 -0800 (PST) Received: by 10.35.58.20 with HTTP; Thu, 16 Mar 2006 10:28:34 -0800 (PST) Message-ID: <953beacc0603161028n37c8459aoba81501c687968cd@mail.gmail.com> Date: Thu, 16 Mar 2006 10:28:34 -0800 From: "Rohan Mahy" To: "Paul Kyzivat" Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <4418E2F9.5040001@cisco.com> MIME-Version: 1.0 References: <440E5E52.20500@cisco.com> <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> <440F9719.4050307@cisco.com> <953beacc0603151749x4fdb2f73ibb32854d3f9385b@mail.gmail.com> <4418E2F9.5040001@cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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="===============1822307439==" Errors-To: sip-bounces@ietf.org --===============1822307439== Content-Type: multipart/alternative; boundary="----=_Part_5038_8058008.1142533714638" ------=_Part_5038_8058008.1142533714638 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Paul, I was actually thinking of a new "1xxrel" option tag. This makes the compatiblity easy for the small percentage that implemented 100rel and trivial for the majority who have not. - Anyone that does not support PRACK now has an easier time implementing th= e new simplified mechanism. Anyone who supports 100rel as a UAC, only has to advertise (in INVITE) and recognize (in 1xx responses) the new option tag in addition to the exiting one. The rest of the UAC behavior is fully RFC 3262 compatible and in most cases identical. Anyone who supports PRACK as a UAS can already unilaterally start RSeqs are 1 and send a provisional every 1 minute (these are both backwards safe). The only additional change is that the UAS does not have to retransmit 1xx responses that are no longer relevant (have been completely replaced by a new response) when using the new version (retransmitting irrelevant 1xx responses is still forward comaptible). Hope this helps. thanks, -rohan On 3/15/06, Paul Kyzivat wrote: > > > > Rohan Mahy wrote: > > > > > > On 3/8/06, *Paul Kyzivat* > > wrote: > > > > > 5) I would deprecate the PRACK/200 (PRACK) offer/answer > exchange. I > > > talked Jonathan into this, and I've been sorry I did ever > since. My > > > apologies to everyone for making a bad decision. > > > > As I mentioned elsewhere, if you deprecate this, then another way i= s > > needed to answer an offer that comes in a reliable provisional. The > only > > obvious way would be to permit an answer in an UPDATE. > > > > > > For clarity, I am suggesting deprecating PRACK (offer) / 200 to PRACK > > (answer). I was no suggesting deprecating reliable 18x (offer) / PRACK > > (answer). > > Oh. I thought you were proposing abandoning PRACK entirely for > offer/answer. (But I haven't really been tracking exactly who has > advocated what.) > > The limited form you suggest is far less troublesome. > > OTOH, I still struggle to understand how removing existing features > simplifies life for anyone. It only gets simpler for those that > implement *only* the new way. So a deployment strategy is required that > allows that. > > Paul > ------=_Part_5038_8058008.1142533714638 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Paul,

I was actually thinking of a new "1xxrel" option = tag.  This makes the compatiblity easy for the small percentage that i= mplemented 100rel and trivial for the majority who have not.

- Anyon= e that does not support PRACK now has an easier time implementing the new s= implified mechanism.

Anyone who supports 100rel as a UAC, only has to advertise (in INVI= TE) and recognize (in 1xx responses) the new option tag in addition to the = exiting one.  The rest of the UAC behavior is fully RFC 3262 compatibl= e and in most cases identical.

Anyone who supports PRACK as a UAS can already unilaterally start R= Seqs are 1 and send a provisional every 1 minute (these are both backwards = safe).  The only additional change is that the UAS does not have to re= transmit 1xx responses that are no longer relevant (have been completely re= placed by a new response) when using the new version (retransmitting irrele= vant 1xx responses is still forward comaptible).

Hope this helps.
thanks,
-rohan


On 3/15/06, Paul Kyzivat= <pkyzivat@cisco.com> wrote= :


Rohan Mah= y wrote:
>
>
> On 3/8/06, *Paul Kyzivat* < pkyzivat@cisco.com
> <mailto:pkyzivat@cisco.com>> wrote:
>
>   = ;   > 5) I would deprecate the PRACK/200 (PRACK) offer/an= swer exchange.  I
>      >= talked Jonathan into this, and I've been sorry I did ever since. &nbs= p;My
>      > apologies to everyone for = making a bad decision.
>
>     As I mention= ed elsewhere, if you deprecate this, then another way is
>  = ;   needed to answer an offer that comes in a reliable provisiona= l. The only
>     obvious way would be to permit an answer i= n an UPDATE.
>
>
> For clarity, I am suggesting deprecati= ng PRACK (offer) / 200 to PRACK
> (answer).  I was no sugge= sting deprecating reliable 18x (offer) / PRACK
> (answer).

Oh. I thought you were proposing abandoning PRACK= entirely for
offer/answer. (But I haven't really been tracking exactly = who has
advocated what.)

The limited form you suggest is far less= troublesome.

OTOH, I still struggle to understand how removing existing features=
simplifies life for anyone. It only gets simpler for those that
impl= ement *only* the new way. So a deployment strategy is required that
allows that.

        Paul

------=_Part_5038_8058008.1142533714638-- --===============1822307439== 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 --===============1822307439==-- From sip-bounces@ietf.org Thu Mar 16 13:47:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxTI-0006VU-Lr; Thu, 16 Mar 2006 13:45:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxTH-0006Uy-6l for sip@ietf.org; Thu, 16 Mar 2006 13:45:15 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJxTF-0003iB-NQ for sip@ietf.org; Thu, 16 Mar 2006 13:45:15 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2GIepK12206; Thu, 16 Mar 2006 13:40:51 -0500 (EST) Received: from [127.0.0.1] ([47.130.18.76] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 13:45:09 -0500 Message-ID: <4419B22E.5090903@nortel.com> Date: Thu, 16 Mar 2006 13:45:02 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Jansson Subject: Re: [Sip] The Problem with PRACK - offerless invite References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2006 18:45:09.0679 (UTC) FILETIME=[C06243F0:01C64929] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 don't understand why there should be a problem, unless it is careless programming. RFC 3264 is totally clear on what the UAC has to do to pick out the session it is interested in. If it doesn't like any of them it ACKs and then does a BYE -- no big deal. Christian Jansson wrote: >>There is certainly no implied bias towards audio in the offerless >>invite. I expect that a UA should offer that which has the capability ... > > So completely depending on Bob's UA, Alice may get _any_ kind of call > back, msrp+audio, video+application/whiteboard, 2 video streams? Even > though Alice initially invited Bob! Why would Alice invite Bob at all if > she does not have _any_ clue of what session Bob will offer? Offerless > invites are useless in practice for anything else than audio, that is a > fact, and I have seen the problems when trying to get things to > interoperate. > > > > >>>Is it possible to build a 3pcc service that sets up a video+voice > > call > >>>using this offerless technique? >> >>Certainly it is possible. > > > Possible, but not in a controllable way. It would be impossible for the > 3pcc to indicate that it should be a video+voice call. > > The only way to get this to work is to create a new extension to let > offerless invites indicate the media that should be included in the > session. But that would also mean that only new UAs that chose to > support that extension would behave well in 3pcc scenarios. > > > (I would say that the sane answer to "I invite you" would be "to what?", > not to start guessing.) > > / Christian Jansson > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 14:06:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxmK-0006Ln-En; Thu, 16 Mar 2006 14:04:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxmI-0006LW-Px for sip@ietf.org; Thu, 16 Mar 2006 14:04:54 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJxmI-0004sK-7b for sip@ietf.org; Thu, 16 Mar 2006 14:04:54 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 16 Mar 2006 11:04:55 -0800 X-IronPort-AV: i="4.02,198,1139212800"; d="scan'208"; a="1785593035:sNHT33564988" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2GJ4q1j007390; Thu, 16 Mar 2006 11:04:53 -0800 (PST) Received: from 10.21.123.199 ([10.21.123.199]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Mar 2006 19:04:52 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 16 Mar 2006 11:04:52 -0800 Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? From: Cullen Jennings To: Samir Srivastava , "Christer Holmberg (JO/LMF)" , Hisham Khartabil , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? Thread-Index: AcZGEMLnAZKxbbIEEdqjXwARJEEJ/ABU9AmAAB7GdDQABQFSYABOM71X In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60AE06946@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If you are going to make the new message so that it is not part of SIP, ie things like Proxy-Require are not used, then it is basically a new protocol and it sounds very similar to just doing some other new protocol over the same transport as the SIP stuff. On 3/14/06 10:18 PM, "Samir Srivastava" wrote: > We cannot differentiate whether OPTIONS is for keep alive or for other > purpose without parsing it > completely. It might have Require and Proxy Require too. That was the > sole purpose of dedicated new message. > > How gaming protocols use STUN i.e. muxing, keep alives ? We might have > Gaming Application and SIP > UA on the same physical Device. > > Thx > Samir > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, March 14, 2006 7:22 PM > To: Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org > Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN > requestprocessingfaster than a SIP PING request processing? > > > Options would not be forwarded if it was sent to the edge proxy. > > > On 3/14/06 4:48 AM, "Christer Holmberg (JO/LMF)" > wrote: > >> >> Hi, >> >> Without commenting on the "speed" issue, IF we want to use a SIP based > >> solution I would prefear a dedicated one, instead of re-using OPTIONS. >> >> Like I said earlier, IF the edge proxy "understands" the mechanism, >> and IF it knows the request does not need to be forwarded, it can >> choose to terminate it. Yes, it's b2bua behaviour, but still. I do not > >> want a solution that forces me to overload the rest of the network >> with the keep-alive requests - no matter what mechanism is used - and >> therefor OPTIONS is not a good solution, because since OPTIONS would >> also be used for non-keep-alive purposes it would always have to be > forwarded. >> >> Another solution, as I mentioned earlier, would be that the >> keep-alives are addressed to the edge proxy (or whatever entity on the > >> other side of the NAT). Then it would be "normal SIP", without any > b2bua behavior. >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 12. maaliskuuta 2006 22:09 >> To: Hisham Khartabil; sip@ietf.org >> Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request >> processingfaster than a SIP PING request processing? >> >> >> You results don't look right to me. I can't really test very well on >> my notebook computer but with STUN on a apple powerbook I am getting >> 16,000 TPS at about 30% CPU. Who knows what I could get with an intel >> processor >> :-) Your results look like 6 to 10k TPS. When people quote ms I never >> have any clue if they are including the kernel time, it it is a >> latency or what. The number we need here is aggregate throughput, not >> latency so actual transactions per second on some suitable box might >> be the easies to compare. >> Similarly, the rates of OPTIONS also looked fairly slow so perhaps I >> just don't get what you are measuring. >> >> Ignoring that, when I look at the code, I can't see any particular >> reason that the speed of PING would not be roughly the same as STUN. >> The problem is this violates RFC 3261 in so many ways that you can >> barely make a list of them all. Once you do the processing to make >> this consistent with existing things, the performance will drop >> significantly >> - my guess is that it would drop to roughly the same rate as OPTION. >> >> >> On 3/6/06 10:02 AM, "Hisham Khartabil" >> wrote: >> >>> I promised to come back with hard real numbers on how long it will >>> take for a server to process and STUN request vs a SIP PING request >>> >>> Myth: processing a STUN request is 10 to 100 times faster than a SIP >>> PING request >>> >>> Assumptions: - SIP PING request is processed early in the stack and >>> bypasses any unnecessary validations. >>> - SIP PING response carries in the contact header the >>> IP address and port as appears in the IP packet (source IP and port). >>> >>> We implemented the PING request as described above in the reSIProcate > >>> stack. Attached you will find the c++ file where the changes were >> made. >>> STUN was already implemented in the reSIProcate stack and used as is. >>> >>> Below you will see the findings: >>> >>> STUN request processing: 0.15 - 0.2 ms SIP PING request processing: >>> 0.1 - 0.2 ms SIP OPTIONS request: 7 ms SIP REGISTER request: 7 ms >>> >>> The measurement was taken between the time a request appeared on >>> ethereal and its response appearing on ethereal. Average was taken >>> manually. >>> >>> As you can see, SIP PING requests were sometimes faster to process >>> that STUN requests, but never slower. Actually the SIP PING requests >>> on average were faster to process. >>> >>> Myth Busted!!!! :) >>> >>> Regards, >>> Hisham >>> P.S. It took 15 mins to modify the sip stack to do the PING response. >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 14:11:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxql-0001Et-KN; Thu, 16 Mar 2006 14:09:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxqk-0001Eo-75 for sip@ietf.org; Thu, 16 Mar 2006 14:09:30 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJxqi-00056x-VH for sip@ietf.org; Thu, 16 Mar 2006 14:09:30 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 16 Mar 2006 11:09:29 -0800 X-IronPort-AV: i="4.02,198,1139212800"; d="scan'208"; a="262363491:sNHT28721012" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2GJ9S1j010399; Thu, 16 Mar 2006 11:09:28 -0800 (PST) Received: from 10.21.123.199 ([10.21.123.199]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Mar 2006 19:09:28 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 16 Mar 2006 11:09:28 -0800 Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request processingfaste r than a SIP PING request processing? From: Cullen Jennings To: Christer Holmberg , Hisham Khartabil , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN request processingfaste r than a SIP PING request processing? Thread-Index: AcZJLSWcZEdXZLUgEdq3fwARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Yes, it would address it to the "outbound proxy" or whatever is the first hop it sends request too. On 3/14/06 11:06 PM, "Christer Holmberg" wrote: > Hi, > > Ok, but that assumes the UAC somehow is told to addree the request to the > proxy, instead of the reote user. Right? > > 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 Mar 16 14:15:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxvG-0001u0-Lr; Thu, 16 Mar 2006 14:14:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxvE-0001rk-PG for sip@ietf.org; Thu, 16 Mar 2006 14:14:08 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJxvD-0005MR-Fy for sip@ietf.org; Thu, 16 Mar 2006 14:14:08 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 16 Mar 2006 11:14:09 -0800 X-IronPort-AV: i="4.02,198,1139212800"; d="scan'208"; a="1785597906:sNHT32075288" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2GJE61j013289; Thu, 16 Mar 2006 11:14:06 -0800 (PST) Received: from 10.21.123.199 ([10.21.123.199]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Mar 2006 19:14:06 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 16 Mar 2006 11:14:07 -0800 Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-02.txt From: Cullen Jennings To: Jeroen van Bemmel , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-02.txt Thread-Index: AcZJLcvoCkToKrUhEdq3fwARJEEJ/A== In-Reply-To: <010701c647a1$414a6860$31713b51@BEMBUSTER> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 3/14/06 11:55 AM, "Jeroen van Bemmel" wrote: > I have just done some basic testing on the Windows (XP) implementation of > TCP keep-alive. > > I used the following code (s = a tcp socket): > > #include // for tcp_keepalive > > int val = TRUE; > ::setsockopt( s, SOL_SOCKET, SO_DONTLINGER, (const char*) &val, > sizeof(val) ); > ::setsockopt( s, SOL_SOCKET, SO_KEEPALIVE, (const char*) &val, > sizeof(val) ); > ::setsockopt( s, IPPROTO_TCP, TCP_NODELAY, (const char*) &val, > sizeof(val) ); > > tcp_keepalive settings; > settings.onoff = 1; > settings.keepaliveinterval = 1000; // interval of a probe when failed, in ms > settings.keepalivetime = 60000; // every X ms, default is 2 hours > DWORD nBytes=0; > int r = ::WSAIoctl( s, SIO_KEEPALIVE_VALS, &settings, sizeof(settings), > NULL, 0, &nBytes, NULL, NULL ); // succeeds, r==0 > > This causes the client to send a TCP keep-alive segment with SEG.SEQ = > SND.NXT-1 as per RFC1122, containing 1 byte of garbage data (byte 00) and DF > flag set. It sends the first probe 60 seconds after the connection has been > idle (I only performed a TCP REGISTER over it), and repeats this every > interval as specified. Different values give different intervals, and other > connections are not affected. The server (a win2k machine I think) responds > with a TCP ACK segment > > My conclusion: This seems usable... agree Thank you. Any chance someone could try the equivalent things on some other OS? particularly Linux and Solaris? OSX? Other versions of windows? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 14:23:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJy25-0002vC-MR; Thu, 16 Mar 2006 14:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJy25-0002v7-6S for sip@ietf.org; Thu, 16 Mar 2006 14:21:13 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJy24-0005Y0-Ti for sip@ietf.org; Thu, 16 Mar 2006 14:21:13 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 16 Mar 2006 11:21:12 -0800 X-IronPort-AV: i="4.02,198,1139212800"; d="scan'208"; a="1785602496:sNHT31001186" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2GJLCw1028747; Thu, 16 Mar 2006 11:21:12 -0800 (PST) Received: from 10.21.123.199 ([10.21.123.199]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Mar 2006 19:21:11 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 16 Mar 2006 11:21:12 -0800 Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt From: Cullen Jennings To: Jeroen van Bemmel , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt Thread-Index: AcZJLsk6B6ciirUiEdq3fwARJEEJ/A== In-Reply-To: <006f01c64792$0abb9260$31713b51@BEMBUSTER> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 3/14/06 10:06 AM, "Jeroen van Bemmel" wrote: >> >> If a proxy hosts two domain one.example.com and two.example.com on the >> same >> IP and port, this does not seem to work. The wrong TLS connection would be >> used. The problem is the cache is populated with the IP/port as the index >> instead of using the cert name as the index. >> > > At first I did not understand your point, until I saw your other posting on > the -04 version: [copy] > > | Second, I don't think it works. If a server runs two virtual domain a.com > | and b.com both on 1.2.3.4:5060 and use the TLS extended hello to separate > | them, then if it connects to C as A.com, and later C wants to send a sips > | message to B.com, it will deliver it over the connection to A.com which is > | totally broken from a security point of view. > > So what you're saying is that a TLS connection should not be used to > multiplex traffic for different virtual domains, even though it is known to > end up at the exact same host and port? Yes exactly, the problem is when the message arrives on a connection that is from both A.com and B.com, the proxy receiving it does not know if it came from A.com or B.com and can't make the appropriate policy decisions on what to do with based on which domain it came from. Proxy often implement white or black list style authorization policy based on where a call came from. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 14:56:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJyYD-0007zH-2n; Thu, 16 Mar 2006 14:54:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJyYB-0007zC-CC for sip@ietf.org; Thu, 16 Mar 2006 14:54:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJyYA-0006Vx-Sz for sip@ietf.org; Thu, 16 Mar 2006 14:54:23 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 16 Mar 2006 11:54:23 -0800 X-IronPort-AV: i="4.02,198,1139212800"; d="scan'208"; a="1785618956:sNHT32988644" 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 k2GJsL1j005283; Thu, 16 Mar 2006 11:54:21 -0800 (PST) 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.211); Thu, 16 Mar 2006 11:54:21 -0800 Received: from [10.21.122.158] ([10.21.122.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 11:54:20 -0800 Message-ID: <4419C26C.8070809@cisco.com> Date: Thu, 16 Mar 2006 14:54:20 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Jansson Subject: Re: [Sip] The Problem with PRACK - offerless invite References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2006 19:54:21.0009 (UTC) FILETIME=[6AC4F410:01C64933] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, Juha Heinanen , "Christer Holmberg \(JO/LMF\)" , Dean Willis , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christian Jansson wrote: >>There is certainly no implied bias towards audio in the offerless >>invite. I expect that a UA should offer that which has the capability > > to > >>do, and that it thinks are appropriate to offer according to its *own* >>current state and context. Ideally in a UA with the capability for more >>than one type of media, the ones to use in this manner would be >>configurable. (E.g. whether to offer video as well as audio.) >> >> >>>But how can Bob know that? Why does Bob not include audio + >>>video + application/whiteboard, etc, etc, and even worse, start all >>>those apps in receiving mode as Bob now has generated the SDP offer? >> >>Depending on the capabilities of the UA, it may well want to do all of >>that. > > > > So completely depending on Bob's UA, Alice may get _any_ kind of call > back, msrp+audio, video+application/whiteboard, 2 video streams? Even > though Alice initially invited Bob! Why would Alice invite Bob at all if > she does not have _any_ clue of what session Bob will offer? Presumably bob wouldn't do this unless this is what he wants. > Offerless > invites are useless in practice for anything else than audio, that is a > fact, and I have seen the problems when trying to get things to > interoperate. In practice, offerless invites are useful in 3pcc scenarios, where there is a controller acting as an intermediary in connecting two other parties. It may not know a priori what either of them support. It just asks one, and takes whatever is offered and offers it to the other. It doesn't care what that is as long as both parties are happy with it. >>>Is it possible to build a 3pcc service that sets up a video+voice > > call > >>>using this offerless technique? >> >>Certainly it is possible. > > > Possible, but not in a controllable way. It would be impossible for the > 3pcc to indicate that it should be a video+voice call. > > The only way to get this to work is to create a new extension to let > offerless invites indicate the media that should be included in the > session. But that would also mean that only new UAs that chose to > support that extension would behave well in 3pcc scenarios. This is true only if you care. Why would a ua that is capable of voice plus video not offer that? Paul > (I would say that the sane answer to "I invite you" would be "to what?", > not to start guessing.) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 15:26:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJz1W-0005sH-0d; Thu, 16 Mar 2006 15:24:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJz1V-0005sC-4R for sip@ietf.org; Thu, 16 Mar 2006 15:24:41 -0500 Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJz1U-0007eT-Ew for sip@ietf.org; Thu, 16 Mar 2006 15:24:41 -0500 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.36 ; Thu, 16 Mar 2006 21:24:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 21:24:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZJJN9t9u/sR974RVKcY+m+63U9bgADsY7g From: "Christian Jansson" To: "Drage, Keith (Keith)" , "Paul Kyzivat" , "Juha Heinanen" X-Spam-Score: 1.5 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, Dean Willis , Brett Tate , "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 >From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >As IETF has not specified a charging model for SIP, or the resources under >the control of SIP, and does not intend to, I would suggest that we have to >assume there is no such restriction, and therefore have to make sure our >protocol supports a multitude of charging cases. Is your opinion that HTTP is big failure just because they did not specify a charging model? Is your opinion that it is impossible to get paid for services on the internet?=20 I think the problem is the vision you have of the walled-in environment, with the "multitude of charging cases", with "all" the specially selected applications that a customer would ever want in the control of the IMS operator. In this environment the user should completely trust his IMS operator, no end-to-end crypto stuff allowed, because as it was said in an earlier mail today, the cscf would probably need to do some "deep inspection" before letting the request go out to the open Internet. In contrast to the trust the user has to have for the operator, the operator does not even trust the user to handle basic sip headers, that is, the topology has to be hidden. Who knows what would happen otherwise, perhaps the user would want to skip/replace some of the nice services that the operator so kindly have provided him with. (To me it seems that the services are more of a service to the operator than to the user?) Of course I think that it should be possible to get paid for delivering VoIP services, but perhaps not exactly the same way as it was designed over 100 years ago, because in that case we could have stayed with PSTN and the GSM systems that we have. / Christian Jansson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 15:56:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzUT-0001Q3-IW; Thu, 16 Mar 2006 15:54:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzUS-0001Pf-6y for sip@ietf.org; Thu, 16 Mar 2006 15:54:36 -0500 Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJzUR-0000Kt-P2 for sip@ietf.org; Thu, 16 Mar 2006 15:54:36 -0500 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.36 ; Thu, 16 Mar 2006 21:54:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The Problem with PRACK - offerless invite Date: Thu, 16 Mar 2006 21:54:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK - offerless invite Thread-Index: AcZJNM5cXCAb94InTn2GuJnR3HTNtwAA3NeQ From: "Christian Jansson" To: "Paul Kyzivat" X-Spam-Score: 1.5 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org, Juha Heinanen , "Christer Holmberg \(JO/LMF\)" , Dean Willis , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> So completely depending on Bob's UA, Alice may get _any_ kind of call >> back, msrp+audio, video+application/whiteboard, 2 video streams? Even >> though Alice initially invited Bob! Why would Alice invite Bob at all if >> she does not have _any_ clue of what session Bob will offer? > >Presumably bob wouldn't do this unless this is what he wants. But what does Alice want? Why did she invite Bob in the first place if she lets Bob decide the type of session without any hint to Bob of what to do? >In practice, offerless invites are useful in 3pcc scenarios, where there >is a controller acting as an intermediary in connecting two other >parties. It may not know a priori what either of them support.=20 I agree, but someone must at least have had an idea of the use of the session that will be created by that 3pcc setup. So a quake+msrp session is as good as an audio+whiteboard session. Shouldn't the initial intention at least be stated, kind of "lets try to setup an 3pcc audio+whiteboard session between Alice and Bob". And then Bob SHOULD use that to build the offer or decline the call? And if Bob tried to use whiteboard+quake he would be considered a little bit strange? > It just >asks one, and takes whatever is offered and offers it to the other. It >doesn't care what that is as long as both parties are happy with it. So, an "anything" session is ok? I guess that will be hard to explain to the users.=20 >This is true only if you care. Why would a ua that is capable of voice >plus video not offer that? Well I do care. Just because I have a video camera and Quake does not mean that I will like to use them all the time. But if the offerless invite at least stated what media types I was expected to use in the offer I could at least take that into consideration when accepting/declining the offerless invite. Is it so that you think that the offer Bob should make should include all supported media types, but that all of them (or configurable) should be inactivated, and that Bob should not be alerted until Alice have decided what media types she decided not to completely deny? After that BoB's UA could ask Bob if he wanted to have an audio+video call, and Bob would then only activate the audio stream in a re-INVITE, as he had a bad-hair-day? / Christian Jansson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 16:00:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzY2-00027V-0k; Thu, 16 Mar 2006 15:58:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzY0-00027Q-La for sip@ietf.org; Thu, 16 Mar 2006 15:58:16 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJzXy-0000Pb-0q for sip@ietf.org; Thu, 16 Mar 2006 15:58:16 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2GKwXNA031984 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 14:58:34 -0600 In-Reply-To: <4419806D.5020604@lucent.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E04CB@zrc2hxm2.corp.nortel.com> <3940774D-5603-4235-9634-7AA5695AA810@softarmor.com> <4418AA55.9080805@lucent.com> <6E3328F0-8364-4569-A104-B847460EE30D@softarmor.com> <4419806D.5020604@lucent.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28C9E7B2-347E-4FC8-8C71-E5ADA2EE3B57@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 16 Mar 2006 14:58:06 -0600 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: "sip@ietf.org List" Subject: [Sip] (Long) Retargeting vs routing of requests and the implications for security and expression of identity. X-BeenThere: sip@ietf.org X-Mailman-Version: 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 directly asked me this question, which I found so compelling I decided I needed to share it with all of you. Please forgive me. On Mar 16, 2006, at 9:12 AM, Vijay K. Gurbani wrote: > Just so that I can catch up with you -- how do you define the > difference > between retargetting and re-routing? To me, the former happens at > the application layer (R-URIs get re-written) while the latter > happens at the network layer (possibly routers re-routing requests, > or applications targetting another server from a set of servers > obtained through DNS SRV). Retargeting is a change in the intended target of a request. In SIP, this manifests as a change in the request URI. Routing is simply delivery of a request to a destination through an intermediary, or delivery of a request to an intermediary that will get it closer to its destination. In SIP, we have the Route header field to describe a vector of intermediaries to visit. In RFC 2543, every proxy operation involved retargeting. We'd pop a Route, change the R-URI, and move on. every proxy operation was a retargeting. In RFC 3261, we introduced the concept of "loose routing", allowing a message to traverse a route vector without changing its request URI. This was a great improvement. However, in RFC 3261, "contact routing" is still a retargeting rather than routing -- the service proxy responsible for an AOR replaces the request URI with the URI registered as the Contact of the intended UA. > In HTTP, the R-URIs do not get re-written (AFAIK), so the way that an > attacker can retarget is by opening a connection to the bad site > and sending the relative URI of the request and the rest of the > request headers there. In SIP, the retargetting is more visible; > i.e., rewrite the R-URI. Yes? In HTTP, a proxy can deliver something to a bogus destination, or issue a redirect. The client sees a redirect -- no problem. This supports response identity, as https allows us to validate the credentialed identity of the responding target against the intended identity (the request-URI). If they don't match, we know we've been bogo-routed. No match, no padlock icon. While the retargeting operation LOOKS more visible in SIP, it's actually completely invisible to the originating UAC. The UAC is never informed that the request has been retargeted, so it has no fixed expectation of who might answer. The strong connection-checking mechanism of https is therefore diluted to a hop-by-hop thing where you have to just hope that all the proxies played nice and that the request got to someplace reasonable. The set of allowable response identities is unbounded, and therefore very hard to validate by the UAC. Also, the UAS has no good way of knowing where the request was supposed to go, and it can't even guess at how it should try and identify itself. This is badly broken. Not only does it break identity, it also keeps us from being able to send URI parameters to the endpoint. This means that for every parameter we might want to pass, we have to have a protocol extension to put it into a header field! Think what the HTTP specs would look like if every CGI parameter you might use in a perl script had to be in an RFC. Insane! Jonathan proposed changing the contact-routing operation so that instead of changing the request URI, the proxy would simply add a Route header populated from the contact. When the request arrives at the UAS, the request-URI will still be the original request-URI, with all its identity statements and parameters intact. Voila, problem fixed. I believe that "retargeting" must be completely eliminated as a proxy operation, and replaced with "redirection". In redirection, the new request-URI is sent back to the UAC, which then has the option of making a new request to that URI. This gives the UAC a target identity against which to evaluate the response, greatly strengthening the security properties. If we take this a step further and make the proxy operation cryptotransparent (like https proxies), then we have even better security properties, because we have a nice solid TLS connection all the way from UAC to UAS, giving us excellent ability to match the request and response identities. By cryptotransparent, we mean that the encrypted stream passes through the proxy without being decrypted and without being modified by the proxy. It might get ROUTED by the proxy, but not modified. Now, there are occasions when you really want the anonymity of hiding behind a proxy. You don't want the correspondent node to know your IP address, or that it's been kicked to an alternate target. These are relatively rare conditions, but they do occur. For this to work right, we need a different sort of relay mechanism. This is where what I call a B2BUAWM, or "back to back user agent with media" becomes applicable. In this model, the originating UAC securely establishes a communication with a UAS. The UAS then acts as a UAC and establishes another independent session to the "final" UAS, and handles relaying the media from one session to the other. With sips engaged, the originating UAC KNOWS that it is talking to the target of its request, as it has done the whole TLS validation with it. This target, the B2BUAWM, knows that it is talking to the right "final UAS", because it too has established a proper TLS connection. In order for this to work, the B2BUAWM has to have the credentials to answer for the request-URI. I call it a "cryptoparticipant" node. It is credentialed and actively engaged in the cryptographic protections, and its presence is known to the other nodes (though they may not know it is a relay). The critical security property here is that requests are ALWAYS either answered by a node that has credentials that match the URI of that request, or with a redirection that gives them a new URI to try instead. If a request is sent be to a different node, we need to change the request URI so that this critical security property is maintained, and we need to inform the user about this retargeting so that the user can provide informed consent. In most cases, no retargeting occurs. Let us consider the classic case of contact routing. Alice calls Bob, who has three registered contacts. I'll simplify a few points, but believe on examination you;ll see how to make them work. Classic model: 1) UA-A establishes TLS connection with ProxyB based on identity from DNS. 2) UA-A sends INVITE to ProxyB. 3) ProxyB has pre-established TLS connections with UA-B1, UA-B2, UA-B3. 4) ProxyB forks INVITE to UA-B1, UA-B2, UA-B3 5) UA-B3 responds with 200 OK to ProxyB 6) ProxyB sends 200OK to UA-A. 7) UA-A establishes TLS connection to UA-B3 and sends ACK,. Question: How does UA-A know that UA-B3 is ok a as a correspondent? It trusts ProxyB to have allowed 200 OK responses only from correspondent nodes separately authenticated by and consequently trusted by ProxyB. NOte also that we have a dependency on DNS security. More likely model, with Record-Routing: 1) UA-A establishes TLS connection with ProxyB based on DNS lookup of Bob's identity from R-URI 2) UA-A sends INVITE to ProxyB. 3) ProxyB has re-established TLS connections with UA-B1, UA-B2, UA-B3. 4) ProxyB forks INVITE to UA-B1, UA-B2, UA-B3 and record-routes. 5) UA-B3 responds with 200 OK to ProxyB 6) ProxyB sends 200OK to UA-A. 7) UA-A sends ACK through ProxyB to UA-B3 Note here that UA-A no longer has any cryptographic interaction with UA-B3. Everything is mediated by ProxyB, at least until we get to the media phase. If B cheats, we won't be able to tell. But ProxyB doesn't really have the credentials to be Bob, just to be ProxyB, and we learned about ProxyB's existence from DNS. Do we trust ProxyB to be responsible for Bob? Even more likely model, with another proxy in front of A. 1) UA-A establishes TLS connection with ProxyA, based on configuration. 2) UA-A sends INVITE to ProxyA. 3) ProxyA establishes TLS connection with ProxyB, based on DNS lookup of Bob's identity from R-URI 4) ProxyA record routes and sends INVITE to ProxyB 5) ProxyB has re-established TLS connections with UA-B1, UA-B2, UA-B3. 6) ProxyB forks INVITE to UA-B1, UA-B2, UA-B3 and record-routes. 7) UA-B3 responds with 200 OK to ProxyB 8) ProxyB sends 200OK to ProxyA 9) ProxyA sends 200OK to UA-A. 10) UA-A sends ACK thru Proxy A and ProxyB to UA-B3 Note here that we're dependent on correct behavior in ProxyA and ProxyB. We have all the problems from the previous case, plus. If ProxyA makes a simple mistake in selecting ProxyB, we could be talking to ANYBODY. We now have a very indirect chain of trust, rooted in DNS having Done the Right Thing. Alternative 1, Purest Form. 1) UA-A establishes TLS connections with UA-B1, UA-B2, UA-B3, selected from DNS. 2) UA-A validates that certificates presented by UA-B1, UA-B2, UA-B3 are valid for Bob. 3) UA-A sends INVITES to UA-B1, UA-B2, UA-B3 4) UA-B3 replies with 200 OK. 5) UA-A sends ACK. Note that here, we have a strongly supported claim that the connected UA is valid for Bob. There is little dependency on correct DNS resolution, because if we got back a bogus target, the credentials wouldn't match and the attack would be detected. Alternative 2, Redirection instead of DNS for target UA Resolution 1) UA-A selects ProxyB using DNS lookup of Bob's identity 2) UA-A establishes TLS connections with ProxyB, validating TLS against identity matching DNS query and "expected domain" 3) UA-A sends INVITE to ProxyB 4) ProxyB responds with a 302 list containing UA-B1, UA-B2, UA-B3 5) UA-A sends new INVITES to UA-B1, UA-B2, UA-B3, establishing TLS and evaluating identities of endpoints 6) UA-B3 responds with a 200 OK. Note that while we still have a partial dependency on DNS, it's cross- validated by a credential that matches the proxy domain we were expecting to see, and the we eventually get to a node that has credentials for Bob (or Bob's phones). Had Bob's proxy sent us to Charlie, we would at least have a trackable record showing that an authentic proxy for Bob sent us to Charlie, and that 2) we were expecting to connect to Charlie as a result, and 3) We really DID connect to Charlie. Now this does point us at some interesting variations. Suppose a 302 could return not just a contact list, but a set of contacts and routes, that would route us through the correct "outbound" proxies for each of Bob's phones? And suppose those proxies were cryptotransparent, so that we could use TLS to validate the final endpoint identity? Cool, huh? But what's cooler is we don't need to change 302 at all to make this work. Instead of returning a set of contacts and routes, Bob's proxy can return a regular Contact list, populated with instance-GRUUs (relative to itself) for each of Bob's contacts. The UAS responds by opening TLS connections through Bob's cryptotransaprent proxy, which applies SIP routing (not retargeting) rules to get the TLS connection pushed through to Bob's UAs. We now have most of the use case of forking, done completely securely, with all the benefits of sip- outbound including last-hop-proxy facilitated keepalives and connection reuse. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 16:04:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzc0-0000lm-Gk; Thu, 16 Mar 2006 16:02:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzby-0000Ky-0l for sip@ietf.org; Thu, 16 Mar 2006 16:02:22 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJzbw-0000bl-Ms for sip@ietf.org; Thu, 16 Mar 2006 16:02:21 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2GL2eL5032052 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 15:02:41 -0600 In-Reply-To: <1142496095.11076.15.camel@eeek.ingate.se> References: <44181E84.8070009@cisco.com> <1142496095.11076.15.camel@eeek.ingate.se> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <377194C9-FFFB-4737-982E-846B3B4687BC@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 Date: Thu, 16 Mar 2006 15:02:13 -0600 To: Hans Persson X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Cullen Jennings , "sip@ietf.org" , Michael Thomas X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 16, 2006, at 2:01 AM, Hans Persson wrote: > ons 2006-03-15 klockan 16:36 -0600 skrev Dean Willis: > >> I believe it's an assertion that the call came from fluffy@cisco.com >> signed not by cisco.com but by ingate.com. > > How do I make such an assertion within the framework of Identity? > As far > as I can tell, a UA compliant with identity-06 will reject such a > request since the domain of the From header does not match the > domain of > the certificate of the signer. Or am I misunderstanding what you mean? > I didn't say it actually worked. That's part of the problem with B2BUAs. -- 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 Mar 16 16:13:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzlM-0001Qx-1k; Thu, 16 Mar 2006 16:12:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzlK-0001Qs-Tc for sip@ietf.org; Thu, 16 Mar 2006 16:12:02 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJzlJ-00011P-JB for sip@ietf.org; Thu, 16 Mar 2006 16:12:02 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2GLCMnw032124 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 15:12:23 -0600 In-Reply-To: <44196CD6.2010707@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <54FCC73F-0A54-4EE8-B3C9-27C8C0D1E612@softarmor.com> <17432.62006.483903.565365@rautu.tutpro.com> <44190887.9030705@cisco.com> <17433.15806.520993.376972@rautu.tutpro.com> <44196CD6.2010707@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <909420E0-170E-4958-86AD-520C0E171906@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 15:11:56 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org, Juha Heinanen , "Christer Holmberg \(JO/LMF\)" , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 16, 2006, at 7:49 AM, Paul Kyzivat wrote: > > > Juha Heinanen wrote: >> Paul Kyzivat writes: >> > Well, I'm pretty sure PRACK was created before SUBSCRIBE. Does >> that mean > that we should trash SUBSCRIBE too? >> if you could have implemented same functionality with existing SIP >> requests, which is not likely with subscribe, but is likely with >> PRACK. > > I guess then that the entire WG was really very stupid to have > approved RFC3262. I feel stupid. It's all my fault! There, better? Now, I would like to point out that there is a difference between formally deprecating something, and just realizing that there are better ways of achieving the goal and using those better ways. I rather like the mention in Adam's Hitchikers Guide of the deprecation of the "future perfect" tense required by the invention of time travel, due to the fact that travelers arriving in the future found it not to have been perfect after all. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 16 16:20:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzrt-0004QA-Jq; Thu, 16 Mar 2006 16:18:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzrs-0004Q3-NN for sip@ietf.org; Thu, 16 Mar 2006 16:18:48 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJzrs-0001En-Dw for sip@ietf.org; Thu, 16 Mar 2006 16:18:48 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2GLJ87u032166 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 15:19:09 -0600 In-Reply-To: <475FF955A05DD411980D00508B6D5FB0124F9601@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0124F9601@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 15:18:42 -0600 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sip@ietf.org, Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" , Juha Heinanen , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 16, 2006, at 12:08 PM, Drage, Keith (Keith) wrote: > Part of Juha's simplifications also assume that the charging models > used by various 3gpp operator's are invalid. > > As IETF has not specified a charging model for SIP, or the > resources under the control of SIP, and does not intend to, I would > suggest that we have to assume there is no such restriction, and > therefore have to make sure our protocol supports a multitude of > charging cases. > > If we wish to start providing such restrictions, then I would > suggest IETF needs to specify the charging model as a means of > identifying those restrictions. However I do not think this is > likely to occur. > > regards > I'll take it the other way. We have no fundamental requirement, in IETF, of even assuring that ANY charging model might possibly be made to work. It is simply not a constraint on our work. Now, where we have agreed to accept specific external requirements or have provided our own requirements, then we would, but only to the extent raised by those agreed requirements. Have we done that for SIP? Personally, I have always argued that anybody attempting to do charging off of SIP-level transactions (for anything more than the delivery of those transactions) is making a fundamental mistake and that the evolution of the protocol is likely to break their assumptions, SO DON'T DO IT! -- 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 Mar 16 16:49:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0JQ-0004EK-4E; Thu, 16 Mar 2006 16:47:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0JP-0004EA-2m for sip@ietf.org; Thu, 16 Mar 2006 16:47:15 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0JO-0002Be-6n for sip@ietf.org; Thu, 16 Mar 2006 16:47:15 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3A501704; Thu, 16 Mar 2006 22:47:13 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 22:47:13 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 22:47:12 +0100 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] The Problem with PRACK Date: Thu, 16 Mar 2006 22:47:11 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B5A@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIVaMg0rCY+ti6TMywrGK1moxUGQA7T3Eg From: "Christer Holmberg \(JO/LMF\)" To: "Brett Tate" , "Paul Kyzivat" X-OriginalArrivalTime: 16 Mar 2006 21:47:12.0933 (UTC) FILETIME=[2F268D50:01C64943] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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, Error response or 200 without SDP - as long as there is a standardized way of doing the rejection. I don't like the send-a-dummy-answer-follwed-by-an-UPDATE approach either. What if the other end can't "unchange"? Regards, Christer -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com]=20 Sent: 15. maaliskuuta 2006 19:28 To: Christer Holmberg (JO/LMF); 'Paul Kyzivat' Cc: 'IETF SIP List' Subject: RE: [Sip] The Problem with PRACK > I'm not sure I see a real problem here. An offer in a prack can't be=20 > the first offer. As a subsequent offer, it is constrained it what it=20 > can contain in such a way that the answer should always be able to=20 > achieve something tolerable, if not desirable. >=20 > [CHH] In theory, the offer could contain one or more new streams. But, > there can also be a technical reason why the receiver simply isn't=20 > capable of processing the offer at the time it is received. >=20 > In any case, I don't a solution where one isn't able to reject an=20 > offer > - for whatever reason... I agree; the UAS should be able to reject the PRACK's offer. The solution presented within draft-sawada-sipping-sip-offeranswer is to answer the offer and trigger an immediate UPDATE to try to change things again. Returning responses like 488, 606, 504, etcetera seem more appropriate. Unfortunately, rfc3262 and rfc3311 did not clearly identify a failure response to send when the UAS cannot accept a PRACK/UPDATE with an offer/answer SDP. This has led to interoperability problems with devices desiring benefits of UPDATE and PRACK; but don't desire/support them containing an SDP. The 504 response mentioned within rfc3311 helps for UPDATE if devices actually support receiving without releasing the call; however it definitely isn't a perfect solution. =20 Returning a 200 response without an SDP to PRACK offer is not a perfect solution and is currently considered non compliant. However it is commonly observed when interworking with devices which implemented (deployed) draft versions of 100rel functionality and are unable/unwilling to disable 100rel usage. And because it isn't explicitly mentioned within the rfc3262, many devices currently do not expect to receive a 504 as discussed within rfc3311. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 16:52:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0MU-0004p0-GO; Thu, 16 Mar 2006 16:50:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0MT-0004oM-7J for sip@ietf.org; Thu, 16 Mar 2006 16:50:25 -0500 Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0MS-0002Fi-OZ for sip@ietf.org; Thu, 16 Mar 2006 16:50:25 -0500 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.36 ; Thu, 16 Mar 2006 22:50:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? Date: Thu, 16 Mar 2006 22:50:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? Thread-Index: AcZJLSWcZEdXZLUgEdq3fwARJEEJ/AADt1ig From: "Christian Jansson" To: X-Spam-Score: 1.5 (+) 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 (Real comment about the subject below ***************) It is interesting to study the design of the 3 protocols (SIP/SDP/STUN) that we currently use. SIP: In SIP anything is possible, you can write your code kind of anyway you want and that should be possible to parse on the other side. I guess SIP is the hippie version of a protocol. No space, many spaces, tabs or no tabs, case-sensitive or case-insensitive, line folding or not, compact form or not compact form, multi value headers and single value headers, name-addr or addr-spec. The most important design principle behind SIP seems to be that the headers can be made to look nice to the human eye. And never decide on just one way of expressing something when there is a possibility that something can be done in more than one way. SDP: SDP is no mr. nice guy when it comes to letting the programmer has his artistic touch affect the look of the messages. The line comes in a strict order v, o, s, ...., no extra spaces allowed, period. Do not even dare to mention \t. Compared to the hippie SIP, SDP is the protocol fascist. STUN: So we had SIP that was perfectly readable for the human eye (but.. hrmmmff a bit more complicated than necessary ..hrrmmff.... for a computer parser), and we had SDP, that was strict and easy to parse but still being human readable. But why not invent a new protocol again :) This time the design principle was performance and size, but importantly, not without being impossible to extend.=20 I never seem to stop wondering why the design principle behind SIP never had performance as a big issue. The most important thing seemed to be that it looked like HTTP, ... even though it wasn't HTTP. And a lot of things with SIP seems to want to look like something even though they really arn't. SBCs and transparent B2BUAs wants to look like proxies, ... even though they aren't. And now someone is suggesting we create a PING request that looks like a SIP message but in fact isn't one. Maybe we should write a draft in this WG that explains the difference between "is a" and "sometimes looks like a". ********************* If anyone gets this far I can at least give my opinion about the current subject: IF we would chose SIP as the protocol for the keep-alive task, let's not overload OPTIONS. OPTIONS already has a task and let's not give it another one that it was not designed for when we have so many other letters in the ASCII set. Haven't we had enough of trying to overload things in SIP (Maybe we could use INFO for the keep-alives.... that would be ....) IF we are saying (in other threads) that SIP over UDP is probably a really bad idea and should perhaps be deprecated, why would it be seen as an advantage to let TCP have the same keep-alives (STUN) as that of another problematic protocol? / Christian Jansson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 16 16:58:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0SE-00024R-9z; Thu, 16 Mar 2006 16:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0SC-0001nn-GP for sip@ietf.org; Thu, 16 Mar 2006 16:56:20 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJzs7-0001Fh-1Y for sip@ietf.org; Thu, 16 Mar 2006 16:19:03 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FJzfg-00016f-0W for sip@ietf.org; Thu, 16 Mar 2006 16:06:12 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2GL6VFN032079 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 15:06:32 -0600 In-Reply-To: <441964EC.7080203@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <17432.61795.685205.596416@rautu.tutpro.com> <441906A9.2090802@cisco.com> <45C84134-9B75-4E45-AF67-F281607DBF6E@softarmor.com> <441964EC.7080203@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 15:06:05 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.746.3) X-Spam-Score: -1.3 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip@ietf.org, Juha Heinanen , "Christer Holmberg \(JO/LMF\)" , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 16, 2006, at 7:15 AM, Paul Kyzivat wrote: > > > Dean Willis wrote: >> On Mar 16, 2006, at 12:33 AM, Paul Kyzivat wrote: >>> >>>> what comes to your example, why can't bob return back a 4xx >>>> response >>>> with security preconditions, the same way authentication works? >>> >>> HERFP. >> No, not if we could match the 4x to a contact-specific target for >> the followon request. > > Huh? In presence of forking this doesn't help. You can only return > one 4xx response. > Well, since it's a "new" 4xx, we could have the proxy that had the poor taste to fork the request roll up the timely responses and throw away the late ones. Not all that pretty, I'll admit. -- 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 Mar 16 17:04:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0YC-0003fQ-6t; Thu, 16 Mar 2006 17:02:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0YA-0003dg-KL for sip@ietf.org; Thu, 16 Mar 2006 17:02:30 -0500 Received: from pproxy.gmail.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0YA-0002mq-9I for sip@ietf.org; Thu, 16 Mar 2006 17:02:30 -0500 Received: by pproxy.gmail.com with SMTP id n25so638483pyg for ; Thu, 16 Mar 2006 14:02:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KGTpgUywC3WmuMaI+Ur6U3DPhGDfXj0uqMvvpgucH7J/VPSY6bU8M1YHwcQNrXoKTem1nmjq2NDbIItT1zZlWcSjI9GazobdQNVojxbXS6Qz3x7D/9KbGhiNypZit97oEPIEXit7TIWikW2Tuwxod7omK+ECiGjQ/pvmdDvZPQ4= Received: by 10.35.70.17 with SMTP id x17mr600638pyk; Thu, 16 Mar 2006 14:02:29 -0800 (PST) Received: by 10.35.58.20 with HTTP; Thu, 16 Mar 2006 14:02:29 -0800 (PST) Message-ID: <953beacc0603161402t36f6db93g8b7f936009d6b12f@mail.gmail.com> Date: Thu, 16 Mar 2006 14:02:29 -0800 From: "Rohan Mahy" To: "Brett Tate" Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <001b01c6490a$7e450170$2c28a8c0@brett1> MIME-Version: 1.0 References: <953beacc0603151846i57f6d3fdm4970043b8e3b9991@mail.gmail.com> <001b01c6490a$7e450170$2c28a8c0@brett1> X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 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="===============0731656999==" Errors-To: sip-bounces@ietf.org --===============0731656999== Content-Type: multipart/alternative; boundary="----=_Part_7142_11064922.1142546549277" ------=_Part_7142_11064922.1142546549277 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Brett, On 3/16/06, Brett Tate wrote: > > > I went back over the 102 messages in this thread and > > did not hear any comments on my concrete proposals: > > > > - require RSeq to start at 1 > > I do not understand how this really helps. The queuing at UAS because of > offer/answer rules (and ensuring dialog established) is still > required. And > if I recall correctly, UPDATEs are now required instead of sending a new > offer within INVITE 18x/2xx. An offer or answer can only appear in INV/first rel18x or first rel 18x/PRACK. You can't have offers or answers in additional 18x responses, o= r with my proposal PRACKs or PRACK responses. The great simplification is that the UAS probably only needs to queue at maximum a single response, and only if the FIRST response (because it contains an offer or answer) is unacknowledged. Are you wanting the UAC to queue out-of-order 18x's? No, the UAC just checks if an incoming provisional has a higher RSeq than the last received RSeq. The last received provisional superceeds the previous ones. (It does not affect the offer/answer state). > - only acknowledge the most recent provisional. > > if the UAS wants to send as new provisional that > > completely replaces a previous one it can send > > immediately. if the UAS wants to send a new > > provisional but wants acknowledgement of a previous > > one, it has to wait for the PRACK. > > I assume RSeq would still be checked so UAC is able to notice out of orde= r > provisional responses. > > It looks like this would impact the current offer/answer rules. Are you > suggesting changes related to offer/answer within first 18x and/or > subsequent 18x's? Even today, you cannot start a subsequent offer/answer exchange in a subsequent 18x, so I'm not suggesting any new offer/answer rules. > - send a provisional every 1 minute whether reliable > > or not. (instead of every one minute for unreliable > > and every 2.5 minutes for reliable) > > I assume this is to better deal with a mixture of reliable and unreliable > transports. The idea sounds fine. However if 100rel is used, I do not > see > a reason to reduce the interval. Did you want Timer C reduced also? It is easier for implementations to do one thing rather than having special case code. Needing to send additional provisionals is so rare anyway, that there is no reason to optimize out the one minute case. I don't see any reason to change Timer C. thanks, -rohan > - deprecate *offers* in PRACK (answers are still OK) > > Sounds good to me. However leaving it is ok if vendors who send it can > deal > with the typical interop problems such as receiving PRACK 200 without an > answer indicating the PRACK's offer was ignored. ------=_Part_7142_11064922.1142546549277 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Brett,

On 3/16/06, Brett Tate <= brett@broadsoft.com> wrote:
> I went back over the 102 messages in this thread and
> did not h= ear any comments on my concrete proposals:
>
> - require RSeq t= o start at 1

I do not understand how this really helps.  T= he queuing at UAS because of
offer/answer rules (and ensuring dialog established) is still required.=   And
if I recall correctly, UPDATEs are now required instead = of sending a new
offer within INVITE 18x/2xx.

An of= fer or answer can only appear in INV/first rel18x   or  first rel= 18x/PRACK.  You can't have offers or answers in additional 18x respon= ses, or with my proposal PRACKs or PRACK responses.=20

The great simplification is that the UAS probably only needs to que= ue at maximum a single response, and only if the FIRST response (because it= contains an offer or answer) is unacknowledged.

Are you wanting the UAC to queue out-of-order 18x's?

N= o, the UAC just checks if an incoming provisional has a higher RSeq than th= e last received RSeq.  The last received provisional superceeds the pr= evious ones.  (It does not affect the offer/answer state).

>= ; - only acknowledge the most recent provisional.
> if the UAS wants = to send as new provisional that
> completely replaces a previous one it can send
> immediately= .  if the UAS wants to send a new
> provisional but wants a= cknowledgement of a previous
> one, it has to wait for the PRACK.
=
I assume RSeq would still be checked so UAC is able to notice out of or= der
provisional responses.

It looks like this would impact the curre= nt offer/answer rules.  Are you
suggesting changes related to = offer/answer within first 18x and/or
subsequent 18x's?
=
Even today, you cannot start a subsequent offer/answer exchange in a su= bsequent 18x, so I'm not suggesting any new offer/answer rules.


> - send a provisional every 1 minute whether reliable
> or not.&= nbsp; (instead of every one minute for unreliable
> and every 2.5 minutes for reliable)

I assume this is to bet= ter deal with a mixture of reliable and unreliable
transports. &nbs= p;The idea sounds fine.  However if 100rel is used, I do not see<= br>a reason to reduce the interval.  Did you want Timer C reduced= also?

It is easier for implementations to do one thing rath= er than having special case code.  Needing to send additional provisio= nals is so rare anyway, that there is no reason to optimize out the one min= ute case.  I don't see any reason to change Timer C.
 
thanks,
-rohan


> - deprecate *offers* in PRACK (answers are= still OK)

Sounds good to me.  However leaving it is ok if vendors w= ho send it can deal
with the typical interop problems such as receiving = PRACK 200 without an
answer indicating the PRACK's offer was ignored.


 

------=_Part_7142_11064922.1142546549277-- --===============0731656999== 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 --===============0731656999==-- From sip-bounces@ietf.org Thu Mar 16 17:06:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0Zx-0004gR-LB; Thu, 16 Mar 2006 17:04:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0Zw-0004gM-9e for sip@ietf.org; Thu, 16 Mar 2006 17:04:20 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0Zv-0002re-RU for sip@ietf.org; Thu, 16 Mar 2006 17:04:20 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3B5736C9; Thu, 16 Mar 2006 23:04:19 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:04:19 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:04:18 +0100 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] The Problem with PRACK Date: Thu, 16 Mar 2006 23:04:18 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B5B@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIm68+bl8yIdkjSN+QI7ryk9rybQAqchWQ From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" , "Dean Willis" X-OriginalArrivalTime: 16 Mar 2006 22:04:18.0742 (UTC) FILETIME=[92949560:01C64945] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, Juha Heinanen , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Paul, Is there something that would NOT work by using UPDATE instead of PRACK? Regards, Christer=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 16. maaliskuuta 2006 3:48 To: Dean Willis Cc: Juha Heinanen; sip@ietf.org; Brett Tate; Christer Holmberg (JO/LMF) Subject: Re: [Sip] The Problem with PRACK Dean, I don't doubt that we could come up with some different model for how to do each thing that would be broken by deprecating PRACK. That means deprecating not only PRACK, but all the other RFCs and drafts that are dependent on it. I'm not sure how many of those there are, probably not a lot, but some. Each of those things will have to either be written off as a bad idea, or else redefined using some other mechanism. I guess if they are all bad ideas then this is clearly the right way to go. If some of those are still things that people want, then that makes more work to do. What you suggest below is a different way to do security preconditions.=20 It could be the germ of a working scheme - or maybe it will be found to be flawed after further study. In any case it will take another cycle of draft development, attention units from ietf participants, and time at ietf meetings. Do we want that? Paul Dean Willis wrote: >=20 > On Mar 15, 2006, at 5:32 PM, Paul Kyzivat wrote: >=20 >> Consider Alice sends offerless invite to Bob. But Bob is only =20 >> willing to do secure calls. So Bob returns an offer in a 183 with =20 >> security preconditions. Bob needs an answer back that releases those >> preconditions before he is willing to ring, much less answer. >=20 >=20 > Off-the-wall response coming. >=20 > How about: >=20 > Bob redirects Alice to himself, along with a precondition qualifier. =20 > Alice satisfies the preconditions, then sends Bob a new INVITE that=20 > indicates the aforementioned preconditions have been satisfied. >=20 > -- > Dean >=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 Mar 16 17:10:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0dp-00081F-GW; Thu, 16 Mar 2006 17:08:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0do-00081A-OF for sip@ietf.org; Thu, 16 Mar 2006 17:08:20 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0dn-0003BE-Df for sip@ietf.org; Thu, 16 Mar 2006 17:08:20 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CC4D24F0001; Thu, 16 Mar 2006 23:08:18 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:08:18 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:08:18 +0100 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] The Problem with PRACK Date: Thu, 16 Mar 2006 23:08:17 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B5C@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIuahxuaW9RHy6SdmflFFBkWEumAAjDVwQ From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , "Paul Kyzivat" X-OriginalArrivalTime: 16 Mar 2006 22:08:18.0278 (UTC) FILETIME=[215AE060:01C64946] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org, Brett Tate , 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 Juha, You seem to blame everything on 3GPP. Are you saying that PRACK and pre-conditions where defined based on requirements from 3GPP? Regards, Christer -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 16. maaliskuuta 2006 7:23 To: Paul Kyzivat Cc: Dean Willis; sip@ietf.org; Brett Tate; Christer Holmberg (JO/LMF) Subject: Re: [Sip] The Problem with PRACK Paul Kyzivat writes: > That means deprecating not only PRACK, but all the other RFCs and > drafts that are dependent on it.=20 the more goes the better. that gives implementers time to catch up and in the meanwhile SIP working group can do their laundry. > Do we want that? what we want is a small number of easy to understand/simple to implement specifications. why you got into this mess was that IETF had no guts to say NO to the walled garden based requirement from 3gpp. now it is high time do so. -- 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 Thu Mar 16 17:17:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0kx-000288-B9; Thu, 16 Mar 2006 17:15:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0kw-000283-78 for sip@ietf.org; Thu, 16 Mar 2006 17:15:42 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0ku-0003N6-IX for sip@ietf.org; Thu, 16 Mar 2006 17:15:42 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 089D74F0001; Thu, 16 Mar 2006 23:15:40 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:15:39 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:15:39 +0100 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] The Problem with PRACK Date: Thu, 16 Mar 2006 23:15:38 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B5D@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIf023XfokgifzSrarR69iUg7cMgAxUnAw From: "Christer Holmberg \(JO/LMF\)" To: "Dean Willis" , "Juha Heinanen" X-OriginalArrivalTime: 16 Mar 2006 22:15:39.0286 (UTC) FILETIME=[28375B60:01C64947] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org, Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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 may missunderstand you, but are you saying that in your world (the non-PSTN one, I assume) it is ok if the phones ring even if there are not enough resources to establish the calls? Regards, Christer=20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: 16. maaliskuuta 2006 0:25 To: Juha Heinanen Cc: Christer Holmberg (JO/LMF); sip@ietf.org; Brett Tate Subject: Re: [Sip] The Problem with PRACK On Mar 14, 2006, at 4:55 PM, Juha Heinanen wrote: > Christer Holmberg (JO/LMF) writes: > >> When 100rel is used it gives a possibility to ACCEPT an offer, and=20 >> send an answer BEFORE 200 OK. > > why is it important for the UAS to accept SDP offer before accepting=20 > or rejecting the invite and why it is important for the UAC to be sure > that UAS has accepted the offer before accepting or rejecting the=20 > invite? > Because people adopted the user-expectations of the PSTN as requirements (a mistake, I believe). In this model, your phone doesn't ring unless there are resources available on the net for the call leg that will exist when you answer. So the model is: 1) Locate target. 2) Establish resources. 3) Notify the user of the target. 4) Talk. Of course, this could all have been done more easily my having first done an exploratory INVITE that returned a contact, using RSVP or NSIS to establish media resources to the contact, and then sending the INVITE to the contact. But people somehow though that doing it in a different order would make the resource management easier. In general, it didn't. -- 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 Mar 16 17:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0l7-00029i-8m; Thu, 16 Mar 2006 17:15:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0l5-000295-If for sip@ietf.org; Thu, 16 Mar 2006 17:15:51 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0l5-0003NE-4Z for sip@ietf.org; Thu, 16 Mar 2006 17:15:51 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 179F74ED; Thu, 16 Mar 2006 23:15:50 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:15:49 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:15:48 +0100 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] The Problem with PRACK Date: Thu, 16 Mar 2006 23:15:48 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B5E@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZIfLNUkhbOoOEeTSCXYepRlQqu5wAxpS9w From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 16 Mar 2006 22:15:48.0900 (UTC) FILETIME=[2DF25640:01C64947] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org, pkyzivat@cisco.com, dean.willis@softarmor.com, princeap@gmail.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 Juha, [CHH] I don't understand why you keep pushing this PRACK problem on me. All I am saying that there may be a need for multiple offer/answer transactions - but that can be done also using UPDATE :)=20 >lets say your mobile UAC first receives a 180 Ringing reply with SDP from an UAS, where the only codec requires 14 Kbps=20 >of bandwidth. before UAC makes the phone ring, it reserves 14 Kbps worth of access bandwidth from the network. after=20 >that the UAC receives 200 OK from ANOTHER UAS, where the only codec requires 64 Kbps of bandwidth. UAC then tries to=20 >increase the reservation, but gets rejected by the network. how does your PRACK complexity with reliable provisional=20 >replies help here to prevent the false ringing tone? [CHH] Of course, if there is NO reliable 18x with an answer before the 200 there is nothing to do - one will have to send the new offer (if needed) AFTER the 200. But, if I get the 64 Kbps answer in a 18x reliable response I can choose to terminate that dialog, and there will be no false ring tones. >Also, I don't know in what environment you are using your SIP phones, =20 >but obvously you don't have to consider the same resource issues as > others must do. >my simple PRACK-free solution DOES consider limited resource issue: when UAC sends an invite, it lists only codecs that=20 >fit into its access bandwidth reservation. at the UAS end, the same happens with codecs in 200 OK reply. when UAC=20 >receives 200 OK, it may be able to reduce its reservation further based on the codec selected in 200 OK. > >this is a very simple working solution that lets us deprecate PRACK. in theory, you may be able to do some small=20 >optimizations, but they are not worth the added complexity. [CHH] "Resources" means more than bandwidth. In a 3G environment you may not have an established PDP context when you send the INVITE, and therefor you indicate "inactive". Later, when you DO have the PDP context, you send a new offer with "sendrecv". 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 Mar 16 17:32:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0z1-0008Q9-Bz; Thu, 16 Mar 2006 17:30:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0yz-0008LO-LR for sip@ietf.org; Thu, 16 Mar 2006 17:30:13 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0yy-00045A-AB for sip@ietf.org; Thu, 16 Mar 2006 17:30:13 -0500 Received: by tutpro.com (Postfix, from userid 65534) id E01CB13F98A; Fri, 17 Mar 2006 00:30:10 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 6B1BD13F989; Fri, 17 Mar 2006 00:30:05 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 2271CF027F; Fri, 17 Mar 2006 00:30:35 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17433.59147.92954.313945@rautu.tutpro.com> Date: Fri, 17 Mar 2006 00:30:35 +0200 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B5D@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1B5D@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sip@ietf.org, Brett Tate , 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) writes: > I may missunderstand you, but are you saying that in your world (the > non-PSTN one, I assume) it is ok if the phones ring even if there are > not enough resources to establish the calls? christer, for resource reservation by SIP UAs, you don't need anything that is not already in RFC3261 as i have shown in earlier messages. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 16 17:35:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK123-0001D6-Dp; Thu, 16 Mar 2006 17:33:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK121-0001Cy-Ue for sip@ietf.org; Thu, 16 Mar 2006 17:33:21 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK121-00048t-70 for sip@ietf.org; Thu, 16 Mar 2006 17:33:21 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 78E2E608; Thu, 16 Mar 2006 23:33:20 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:33:20 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:33:20 +0100 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] The Problem with PRACK Date: Thu, 16 Mar 2006 23:33:19 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B60@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZJRYHctMiFsMz4Sea0CeQ15YF3ngAArLtA From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" , "Brett Tate" X-OriginalArrivalTime: 16 Mar 2006 22:33:20.0177 (UTC) FILETIME=[A08E7A10:01C64949] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 > I went back over the 102 messages in this thread and > did not hear any comments on my concrete proposals: > > - require RSeq to start at 1 =09 >I do not understand how this really helps. The queuing at UAS because of=20 >offer/answer rules (and ensuring dialog established) is still required. And >if I recall correctly, UPDATEs are now required instead of sending a new >offer within INVITE 18x/2xx. >An offer or answer can only appear in INV/first rel18x or first rel 18x/PRACK. >You can't have offers or answers in additional 18x responses, or with my proposal PRACKs or PRACK responses.=20 >The great simplification is that the UAS probably only needs to queue at maximum a single response, and only if the FIRST=20 >response (because it contains an offer or answer) is unacknowledged. [CHH] What you say is not completely true. It IS said, that if the INV does not contain an offer, the offer MUST come in the FIRST rel18x (a rule I also think we should get rid of). But, if the INV does contain an offer, it is nowhere said that the first rel18x must contain the answer. >Are you wanting the UAC to queue out-of-order 18x's? > >No, the UAC just checks if an incoming provisional has a higher RSeq than the last received RSeq. The last received=20 >provisional superceeds the previous ones. (It does not affect the offer/answer state).=20 [CHH] This is similar to my proposal to indicate the first RSeq in the INVITE. But, mandating the first value to be 1 is ok too. > - only acknowledge the most recent provisional. > if the UAS wants to send as new provisional that=20 > completely replaces a previous one it can send > immediately. if the UAS wants to send a new > provisional but wants acknowledgement of a previous > one, it has to wait for the PRACK. =09 >I assume RSeq would still be checked so UAC is able to notice out of order=20 >provisional responses. [CHH] What to you mean by "replace a provisional response"??? =09 >It looks like this would impact the current offer/answer rules. Are you >suggesting changes related to offer/answer within first 18x and/or >subsequent 18x's? > >Even today, you cannot start a subsequent offer/answer exchange in a subsequent 18x, so I'm not suggesting any new=20 >offer/answer rules.=20 [CHH] I agree that you should not be able to carry additional offer/answers in subsequent 18x. However, as I said, I don't agree that it is mandated to send an answer in the first rel18x, and I DO think we should get rid of the rule by mandating an offer in the first rel18x (if the INV didn't carry an offer). 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 Mar 16 17:36:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK13C-0002AZ-I3; Thu, 16 Mar 2006 17:34:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK13A-0002AH-Q1 for sip@ietf.org; Thu, 16 Mar 2006 17:34:32 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK13A-0004BB-F2 for sip@ietf.org; Thu, 16 Mar 2006 17:34:32 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2GMYVlW010142; Thu, 16 Mar 2006 16:34:31 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2GMYV319996; Thu, 16 Mar 2006 16:34:31 -0600 (CST) Message-ID: <4419E7F6.70601@lucent.com> Date: Thu, 16 Mar 2006 16:34:30 -0600 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] (Long) Retargeting vs routing of requests and the implications for security and expression of identity. References: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E04CB@zrc2hxm2.corp.nortel.com> <3940774D-5603-4235-9634-7AA5695AA810@softarmor.com> <4418AA55.9080805@lucent.com> <6E3328F0-8364-4569-A104-B847460EE30D@softarmor.com> <4419806D.5020604@lucent.com> <28C9E7B2-347E-4FC8-8C71-E5ADA2EE3B57@softarmor.com> In-Reply-To: <28C9E7B2-347E-4FC8-8C71-E5ADA2EE3B57@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: "sip@ietf.org 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="===============1981052614==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1981052614== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080008010708050607010506" This is a cryptographically signed message in MIME format. --------------ms080008010708050607010506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dean Willis wrote: > > Vijay directly asked me this question, which I found so compelling I > decided I needed to share it with all of you. Please forgive me. OK, if you insist. Of course, question inline. [...] > But what's cooler is we don't need to change 302 at all to make this > work. Instead of returning a set of contacts and routes, Bob's proxy > can return a regular Contact list, populated with instance-GRUUs > (relative to itself) for each of Bob's contacts. The UAS responds by ^^^ I think you meant "UAC" +------------------------------| > opening TLS connections through Bob's cryptotransaprent proxy, which > applies SIP routing (not retargeting) rules to get the TLS connection > pushed through to Bob's UAs. We now have most of the use case of > forking, done completely securely, with all the benefits of sip- > outbound including last-hop-proxy facilitated keepalives and connection > reuse. I was with you all the way until here. So ... Bob's proxy returns a Contact list, populated with instance GRUUs relative to itself. We'll come back here. As I understand it, in HTTP cryptotransparency across proxies is obtained by upgrading a normal TCP connection from browser to origin server through proxies to use TLS once a tunnel is set up (rfc2817). After the the tunnel is established, an upgrade is requested and certs are exchanged directly between the browser and the origin server. Now, how does this map into our SIP case? When Alice's UA got a Contact list, it already had a TLS connection established with Bob's proxy. Over this TLS connection, it sends multiple requests to simulate endpoint forking (let's assume you like endpoint forking as opposed to proxy forking, which I know for a fact that you dont' :-)). Bob's proxy now applies SIP routing to get to Bob's UA. Are you saying somehow that Bob's proxy will send Alice's cert to Bob's UA and Bob's cert to Alice's UA and have Bob and Alice do the TLS handshake to negotiate session keys such that the proxy can now be cryptotransparent? Or are you saying that we need an analogous method to rfc2817 such that Alice's UA establishes a TCP tunnel to each of Bob's user agents and then an upgrade happens to cause each of Bob's user agents to send their respective certs to Alice? Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms080008010708050607010506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMTYyMjM0MzBaMCMGCSqGSIb3DQEJ BDEWBBRwJlHPclF4gdEL8suF9G9hQl5HADBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAWOTEB4+aLULv0UbZyMiqxPWz2+CJYMdf/H3ghrlVbD+BxE6bHgjP Kr+VjWb0DvdQj905sqCyGfXUyZFUcg85lZFTIWZr7kqTyfJDNOjXzxqIJLXA0QTZDk6ho5rW pf7X/8pG1Pd2p02iQFgpoc+CI6jdgUiUHNs6eBPr50RwP7EAAAAAAAA= --------------ms080008010708050607010506-- --===============1981052614== 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 --===============1981052614==-- From sip-bounces@ietf.org Thu Mar 16 17:42:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK18n-0005qf-4S; Thu, 16 Mar 2006 17:40:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK18l-0005p5-Mw for sip@ietf.org; Thu, 16 Mar 2006 17:40:19 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK18l-0004LF-7J for sip@ietf.org; Thu, 16 Mar 2006 17:40:19 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 8AF65140401; Fri, 17 Mar 2006 00:40:18 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 0669B13F98A; Fri, 17 Mar 2006 00:40:08 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id C5E9AF027F; Fri, 17 Mar 2006 00:40:37 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17433.59749.763134.140834@rautu.tutpro.com> Date: Fri, 17 Mar 2006 00:40:37 +0200 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B5E@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1B5E@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org, pkyzivat@cisco.com, dean.willis@softarmor.com, princeap@gmail.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 Christer Holmberg (JO/LMF) writes: > [CHH] I don't understand why you keep pushing this PRACK problem on > me. christer, not personally on you, but on anyone who thinks PRACK is a good idea. as i told, i got pissed off by PRACK, when SIP phones that used to interoperate fine with everybody stopped doing so when they included PRACK support and i as a proxy programmer started getting email from angry customers although i had nothing to do with their problems. > All I am saying that there may be a need for multiple offer/answer > transactions - but that can be done also using UPDATE :) there you go! so we can finally deprecate PRACK and have one SIP request less. > [CHH] Of course, if there is NO reliable 18x with an answer before the > 200 there is nothing to do - one will have to send the new offer (if > needed) AFTER the 200. But, if I get the 64 Kbps answer in a 18x > reliable response I can choose to terminate that dialog, and there will > be no false ring tones. there IS reliable 180 Ringing from ONE of the forks and then you get 200 OK from another fork with higher demand. does your phone ring or not after the reliable 180? > [CHH] "Resources" means more than bandwidth. In a 3G environment you may > not have an established PDP context when you send the INVITE, and > therefor you indicate "inactive". Later, when you DO have the PDP > context, you send a new offer with "sendrecv". that is clearly something you 3gpp folks need to fix in your system rather than messing up SIP with PRACK. -- 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 Thu Mar 16 17:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1BF-00009f-K7; Thu, 16 Mar 2006 17:42:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1BD-00009C-TI for sip@ietf.org; Thu, 16 Mar 2006 17:42:51 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK1BD-0004OK-Fx for sip@ietf.org; Thu, 16 Mar 2006 17:42:51 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E0B5A608; Thu, 16 Mar 2006 23:42:50 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:42:50 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:42:50 +0100 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] The Problem with PRACK Date: Thu, 16 Mar 2006 23:42:49 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B61@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZJSTLVjKzMhDR6QQ6RvMDEPPsxWQAAK0NA From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 16 Mar 2006 22:42:50.0381 (UTC) FILETIME=[F46CB3D0:01C6494A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org, Brett Tate , 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 Juha, If you don't like the 3GPP way of sending an INVITE before the PDP context has been fully established (i.e. if think it would be better to establish everything before you send the INVITE) I think you should go to 3GPP and express that view. This is not the right place. And, 3GPP is using mechanisms defined by IETF do to this, so I really don't understand your 3GPP/walled garden "flaming". 3GPP did not define PRACK, or the pre-condition mechanism. Regards, Christer =20 -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 17. maaliskuuta 2006 0:31 To: Christer Holmberg (JO/LMF) Cc: Dean Willis; sip@ietf.org; Brett Tate Subject: RE: [Sip] The Problem with PRACK Christer Holmberg (JO/LMF) writes: > I may missunderstand you, but are you saying that in your world (the > non-PSTN one, I assume) it is ok if the phones ring even if there are > not enough resources to establish the calls? christer, for resource reservation by SIP UAs, you don't need anything that is not already in RFC3261 as i have shown in earlier messages. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 16 17:56:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1Mj-0000hA-QK; Thu, 16 Mar 2006 17:54:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1Mi-0000h0-0B for sip@ietf.org; Thu, 16 Mar 2006 17:54:44 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK1Mh-0004lF-EI for sip@ietf.org; Thu, 16 Mar 2006 17:54:43 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CCDCE788; Thu, 16 Mar 2006 23:54:42 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:54:42 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 23:54:42 +0100 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] The Problem with PRACK Date: Thu, 16 Mar 2006 23:54:41 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B62@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZJSptCOkJ/f32LRfe0pd0kHP8CMQAAG45g From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 16 Mar 2006 22:54:42.0287 (UTC) FILETIME=[9CC0EFF0:01C6494C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip@ietf.org, pkyzivat@cisco.com, dean.willis@softarmor.com, princeap@gmail.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,=20 >[CHH] I don't understand why you keep pushing this PRACK problem on > me. > >christer, > >not personally on you, but on anyone who thinks PRACK is a good idea. >as i told, i got pissed off by PRACK, when SIP phones that used to interoperate fine with everybody stopped doing so when >they included PRACK support and i as a proxy programmer started getting email from angry customers although i had nothing >to do with their problems. [CHH] All PRACK supporting SIP phones I've seen have worked fine - when it comes to using PRACK purely for providing reliable provisional responses.=20 This discussion is about the usage of PRACK for offer/answer, and I DO agree with you that there are issues there :) >All I am saying that there may be a need for multiple offer/answer =20 >transactions - but that can be done also using UPDATE :)=20 > >there you go! so we can finally deprecate PRACK and have one SIP request less. [CHH] Well, you still need to be able to send the SDP in a reliable 18x, and currently PRACK is the only way to do that. But, as I said, that doesn't mean you would have to send SDP in the PRACK itself - you could use UPDATE. >[CHH] Of course, if there is NO reliable 18x with an answer before the >200 there is nothing to do - one will have to send the new offer (if =20 >needed) AFTER the 200. But, if I get the 64 Kbps answer in a 18x =20 >reliable response I can choose to terminate that dialog, and there will >be no false ring tones. > >there IS reliable 180 Ringing from ONE of the forks and then you get 200 OK from another fork with higher demand. does=20 >your phone ring or not after the reliable 180? [CHH] What you are talking about now is the problem with forking. That is a completely separate issue, I think. I mean, you could get a 18x from a user, and a 4xx from the other user (or even the same user that send 18x), and you would still get a "false" ring tone. That is a "SIP feature". >[CHH] "Resources" means more than bandwidth. In a 3G environment you may =20 >not have an established PDP context when you send the INVITE, and =20 >therefor you indicate "inactive". Later, when you DO have the PDP =20 >context, you send a new offer with "sendrecv". > >that is clearly something you 3gpp folks need to fix in your system rather than messing up SIP with PRACK. [CHH] If you have a look at the new alternative 3GPP procedures, where the pre-condition flows are not used, you will see that PRACK is NOT (unless I remember wrong) mandated to carry SDP (you can use UPDATE instead). PRACK is ONLY used when you need to acknowledge a rel18x with SDP. 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 Mar 16 17:58:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1Op-0001wo-Qt; Thu, 16 Mar 2006 17:56:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1Oo-0001vC-C2 for sip@ietf.org; Thu, 16 Mar 2006 17:56:54 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK1Oo-0004vK-0W for sip@ietf.org; Thu, 16 Mar 2006 17:56:54 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 5FAC4140401; Fri, 17 Mar 2006 00:56:53 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id B80951403EF; Fri, 17 Mar 2006 00:56:47 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id BB3A3F027F; Fri, 17 Mar 2006 00:57:15 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17433.60747.723994.971274@rautu.tutpro.com> Date: Fri, 17 Mar 2006 00:57:15 +0200 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B61@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1B61@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, Brett Tate , 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) writes: > If you don't like the 3GPP way of sending an INVITE before the PDP > context has been fully established (i.e. if think it would be better to > establish everything before you send the INVITE) I think you should go > to 3GPP and express that view. This is not the right place. i could care less if 3GPP system works or not and have no business to go there. i just told how you can make resource reservation w/o PRACK. > And, 3GPP is using mechanisms defined by IETF do to this, so I really > don't understand your 3GPP/walled garden "flaming". 3GPP did not define > PRACK, or the pre-condition mechanism. i apologize if 3GPP requirements had nothing to do with introduction of PRACK in SIP. regarding "walled garden" flaming stuff, see another ongoing thread on one of these list on IETF support of 3GPP charging models. -- 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 Thu Mar 16 18:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1TM-0004US-1M; Thu, 16 Mar 2006 18:01:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1TK-0004UI-CP for sip@ietf.org; Thu, 16 Mar 2006 18:01:34 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK1TJ-00057L-21 for sip@ietf.org; Thu, 16 Mar 2006 18:01:34 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 830181B2; Fri, 17 Mar 2006 00:01:32 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 00:01:32 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 00:01:32 +0100 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] The Problem with PRACK Date: Fri, 17 Mar 2006 00:01:31 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B63@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZJTOtgNyYSz9JPRjmsY20ZLpxrZAAACnMg From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 16 Mar 2006 23:01:32.0016 (UTC) FILETIME=[90F89F00:01C6494D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, Brett Tate , 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 >If you don't like the 3GPP way of sending an INVITE before the PDP =20 >context has been fully established (i.e. if think it would be better to >establish everything before you send the INVITE) I think you should go >to 3GPP and express that view. This is not the right place. i could care less if 3GPP system works or not and have no business to go there. i just told how you can make resource reservation w/o PRACK. [CHH] And I think everybody agrees on that. The PROBLEM is that people claim there are implementations using mechanisms that so far HAVE been allowed. >And, 3GPP is using mechanisms defined by IETF do to this, so I really =20 >don't understand your 3GPP/walled garden "flaming". 3GPP did not define >PRACK, or the pre-condition mechanism. >i apologize if 3GPP requirements had nothing to do with introduction of PRACK in SIP. regarding "walled garden" flaming=20 >stuff, see another ongoing thread on one of these list on IETF support of 3GPP charging models. [CHH] You may of course have other reasons to flame the walled gardens, but I was refering to a specific topic :) 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 Mar 16 18:41:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK241-0008PD-67; Thu, 16 Mar 2006 18:39:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK23z-0008Kr-SX for sip@ietf.org; Thu, 16 Mar 2006 18:39:27 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK23y-0007H6-Ih for sip@ietf.org; Thu, 16 Mar 2006 18:39:27 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2GNdi8Q000435 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 17:39:46 -0600 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B5D@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1B5D@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Thu, 16 Mar 2006 17:39:17 -0600 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip@ietf.org, Juha Heinanen , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 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, this has gone on long enough. You people aren't even reading anymore. -- Dean On Mar 16, 2006, at 4:15 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi Dean, > > I may missunderstand you, but are you saying that in your world (the > non-PSTN one, I assume) it is ok if the phones ring even if there are > not enough resources to establish the calls? > > Regards, > > Christer > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 16. maaliskuuta 2006 0:25 > To: Juha Heinanen > Cc: Christer Holmberg (JO/LMF); sip@ietf.org; Brett Tate > Subject: Re: [Sip] The Problem with PRACK > > > On Mar 14, 2006, at 4:55 PM, Juha Heinanen wrote: > >> Christer Holmberg (JO/LMF) writes: >> >>> When 100rel is used it gives a possibility to ACCEPT an offer, and >>> send an answer BEFORE 200 OK. >> >> why is it important for the UAS to accept SDP offer before accepting >> or rejecting the invite and why it is important for the UAC to be >> sure > >> that UAS has accepted the offer before accepting or rejecting the >> invite? >> > Because people adopted the user-expectations of the PSTN as > requirements > (a mistake, I believe). > > In this model, your phone doesn't ring unless there are resources > available on the net for the call leg that will exist when you answer. > > So the model is: 1) Locate target. 2) Establish resources. 3) > Notify the > user of the target. 4) Talk. > > Of course, this could all have been done more easily my having first > done an exploratory INVITE that returned a contact, using RSVP or NSIS > to establish media resources to the contact, and then sending the > INVITE > to the contact. But people somehow though that doing it in a different > order would make the resource management easier. In general, it > didn't. > > -- > 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 Mar 16 18:43:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK25j-0002QL-8X; Thu, 16 Mar 2006 18:41:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK25h-0002QG-TL for sip@ietf.org; Thu, 16 Mar 2006 18:41:13 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK25h-0007KA-Jl for sip@ietf.org; Thu, 16 Mar 2006 18:41:13 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2GNfX0j000451 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 17:41:34 -0600 In-Reply-To: <4419E7F6.70601@lucent.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710D6E04CB@zrc2hxm2.corp.nortel.com> <3940774D-5603-4235-9634-7AA5695AA810@softarmor.com> <4418AA55.9080805@lucent.com> <6E3328F0-8364-4569-A104-B847460EE30D@softarmor.com> <4419806D.5020604@lucent.com> <28C9E7B2-347E-4FC8-8C71-E5ADA2EE3B57@softarmor.com> <4419E7F6.70601@lucent.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <58677ED5-3C75-4408-8628-AD10BFC96734@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] (Long) Retargeting vs routing of requests and the implications for security and expression of identity. Date: Thu, 16 Mar 2006 17:41:07 -0600 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "sip@ietf.org 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 On Mar 16, 2006, at 4:34 PM, Vijay K. Gurbani wrote: > > Or are you saying that we need an analogous method to rfc2817 > such that Alice's UA establishes a TCP tunnel to each of Bob's > user agents and then an upgrade happens to cause each of Bob's user > agents to send their respective certs to Alice? > yes, that's one of the better alternatives. -- 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 Mar 16 20:58:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4Cj-0001GG-EZ; Thu, 16 Mar 2006 20:56:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4Ci-0001GB-CE for sip@ietf.org; Thu, 16 Mar 2006 20:56:36 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK4Ch-0003B8-2G for sip@ietf.org; Thu, 16 Mar 2006 20:56:36 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2006 02:56:34 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2H1uX36012615; Fri, 17 Mar 2006 02:56:33 +0100 (MET) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 17 Mar 2006 02:56:33 +0100 Received: from [10.61.64.61] ([10.61.64.61]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 16 Mar 2006 17:56:32 -0800 Message-ID: <441A174E.2040801@cisco.com> Date: Thu, 16 Mar 2006 20:56:30 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] The Problem with PRACK References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <17432.61795.685205.596416@rautu.tutpro.com> <17433.16194.547665.704204@rautu.tutpro.com> <44196428.6080800@cisco.com> <17433.26719.823233.167864@rautu.tutpro.com> In-Reply-To: <17433.26719.823233.167864@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2006 01:56:32.0739 (UTC) FILETIME=[03E3CB30:01C64966] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 Heinanen wrote: > Paul Kyzivat writes: > > > I think we are all getting confused here. Alice called Bob, so Bob won't > > ever get a 180. Bob's phone will start to ring when all preconditions > > for both alice and bob have been satisfied. At that same time Bob will > > send a 180 to Alice, and Alice will begin to hear ringback. > > what about if he call gets forked to another plain old RFC3261 UA that > replies with 200 OK after 180 has come from Bob to Alice? Then alice gets to talk to Bob on the phone that answered rather than the one that didn't. 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 Mar 16 21:07:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4LW-00072z-0e; Thu, 16 Mar 2006 21:05:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4LU-0006ws-Ux for sip@ietf.org; Thu, 16 Mar 2006 21:05:40 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK4LU-0003ZJ-K7 for sip@ietf.org; Thu, 16 Mar 2006 21:05:40 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2006 03:05:40 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2H25d36013619; Fri, 17 Mar 2006 03:05:39 +0100 (MET) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 17 Mar 2006 03:05:39 +0100 Received: from [10.61.64.61] ([10.61.64.61]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 17 Mar 2006 03:05:39 +0100 Message-ID: <441A1971.3090005@cisco.com> Date: Thu, 16 Mar 2006 21:05:37 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] The Problem with PRACK References: <5EB80D22825EEE42872083AD5BFFB5945D1B5B@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B5B@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2006 02:05:39.0191 (UTC) FILETIME=[4999C070:01C64967] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org, Juha Heinanen , Brett Tate , 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: > Hi Paul, > > Is there something that would NOT work by using UPDATE instead of PRACK? If you mean for sending an *offer*, then UPDATE can work as well as prack, at the expense of two more messages. But UPDATE doesn't substitute for sending an answer to an offer received in a reliable 1xx. What would *not* work are UAs that are currently programmed to use PRACK to send offers. Paul > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 16. maaliskuuta 2006 3:48 > To: Dean Willis > Cc: Juha Heinanen; sip@ietf.org; Brett Tate; Christer Holmberg (JO/LMF) > Subject: Re: [Sip] The Problem with PRACK > > Dean, > > I don't doubt that we could come up with some different model for how to > do each thing that would be broken by deprecating PRACK. That means > deprecating not only PRACK, but all the other RFCs and drafts that are > dependent on it. I'm not sure how many of those there are, probably not > a lot, but some. Each of those things will have to either be written off > as a bad idea, or else redefined using some other mechanism. I guess if > they are all bad ideas then this is clearly the right way to go. If some > of those are still things that people want, then that makes more work to > do. > > What you suggest below is a different way to do security preconditions. > It could be the germ of a working scheme - or maybe it will be found to > be flawed after further study. In any case it will take another cycle of > draft development, attention units from ietf participants, and time at > ietf meetings. Do we want that? > > Paul > > Dean Willis wrote: > >>On Mar 15, 2006, at 5:32 PM, Paul Kyzivat wrote: >> >> >>>Consider Alice sends offerless invite to Bob. But Bob is only >>>willing to do secure calls. So Bob returns an offer in a 183 with >>>security preconditions. Bob needs an answer back that releases those > > >>>preconditions before he is willing to ring, much less answer. >> >> >>Off-the-wall response coming. >> >>How about: >> >>Bob redirects Alice to himself, along with a precondition qualifier. >>Alice satisfies the preconditions, then sends Bob a new INVITE that >>indicates the aforementioned preconditions have been satisfied. >> >>-- >>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 Mar 16 21:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4PN-00058M-Fw; Thu, 16 Mar 2006 21:09:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4PL-00058A-Lo for sip@ietf.org; Thu, 16 Mar 2006 21:09:39 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK4PK-0003k7-An for sip@ietf.org; Thu, 16 Mar 2006 21:09:39 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 0B3621403EC; Fri, 17 Mar 2006 04:09:37 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 0AE1E1403E4; Fri, 17 Mar 2006 04:09:30 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id CE74EF027F; Fri, 17 Mar 2006 04:09:27 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17434.6743.799554.383272@rautu.tutpro.com> Date: Fri, 17 Mar 2006 04:09:27 +0200 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <441A174E.2040801@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1B52@esealmw113.eemea.ericsson.se> <17431.18912.266470.211444@rautu.tutpro.com> <212D5C60-F9DF-401D-928C-1A32A3A54761@softarmor.com> <17432.38508.791558.810529@rautu.tutpro.com> <44189E1F.4090603@cisco.com> <17432.41089.313369.873317@rautu.tutpro.com> <4418A41F.20803@cisco.com> <17432.61795.685205.596416@rautu.tutpro.com> <17433.16194.547665.704204@rautu.tutpro.com> <44196428.6080800@cisco.com> <17433.26719.823233.167864@rautu.tutpro.com> <441A174E.2040801@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org, Brett Tate , "Christer Holmberg \(JO/LMF\)" , 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 writes: > Then alice gets to talk to Bob on the phone that answered rather than > the one that didn't. the point was that Alice doesn't want to talk to anyone whose preconditions were not filled. but we can leave this now and go back to work. -- 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 Thu Mar 16 21:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4lF-0006rx-Sg; Thu, 16 Mar 2006 21:32:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4lE-0006rs-Rn for sip@ietf.org; Thu, 16 Mar 2006 21:32:16 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK4lE-0004OB-BS for sip@ietf.org; Thu, 16 Mar 2006 21:32:16 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2006 03:32:16 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2H2WF36016046; Fri, 17 Mar 2006 03:32:15 +0100 (MET) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 17 Mar 2006 03:32:14 +0100 Received: from [10.61.64.61] ([10.61.64.61]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 17 Mar 2006 03:32:14 +0100 Message-ID: <441A1FAB.4090700@cisco.com> Date: Thu, 16 Mar 2006 21:32:11 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Jansson Subject: Re: [Sip] The Problem with PRACK - offerless invite References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2006 02:32:14.0374 (UTC) FILETIME=[00675C60:01C6496B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: sip@ietf.org, Juha Heinanen , "Christer Holmberg \(JO/LMF\)" , Dean Willis , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christian Jansson wrote: >>>So completely depending on Bob's UA, Alice may get _any_ kind of call >>>back, msrp+audio, video+application/whiteboard, 2 video streams? Even >>>though Alice initially invited Bob! Why would Alice invite Bob at all > > if > >>>she does not have _any_ clue of what session Bob will offer? >> >>Presumably bob wouldn't do this unless this is what he wants. > > > But what does Alice want? Why did she invite Bob in the first place if > she lets Bob decide the type of session without any hint to Bob of what > to do? I'm sorry - I typed the wrong thing. What I meant to say was: presumably *alice* wouldn't do this (send an offerless invite) unless this (getting an unpredictable offer) is what *she* wants. >>In practice, offerless invites are useful in 3pcc scenarios, where > > there > >>is a controller acting as an intermediary in connecting two other >>parties. It may not know a priori what either of them support. > > > I agree, but someone must at least have had an idea of the use of the > session that will be created by that 3pcc setup. This is all context sensitive. The user controlling the B2BUA may be familiar with at least one of the UAs that will be used, and so has an expectation that the resulting session will involve some or all of the media supported by that UA. But that doesn't mean that the B2BUA needs to know. It seems unlikely that someone with no knowledge of either UA would be interested in establishing a session between them. > So a quake+msrp session > is as good as an audio+whiteboard session. Shouldn't the initial > intention at least be stated, kind of "lets try to setup an 3pcc > audio+whiteboard session between Alice and Bob". And then Bob SHOULD use > that to build the offer or decline the call? And if Bob tried to use > whiteboard+quake he would be considered a little bit strange? This is technically difficult to do with a B2BUA, unless it terminates media. Making an offer with media means specifying a media address. This can partially be mitigated by offering media with C=0.0.0.0, but then you can get some ugly clipping issues. (The clipping issues could be solved using preconditions, but lets not go there right now.) >>It just >>asks one, and takes whatever is offered and offers it to the other. It >>doesn't care what that is as long as both parties are happy with it. > > > So, an "anything" session is ok? I guess that will be hard to explain to > the users. > > >>This is true only if you care. Why would a ua that is capable of voice >>plus video not offer that? > > > Well I do care. Just because I have a video camera and Quake does not > mean that I will like to use them all the time. But if the offerless > invite at least stated what media types I was expected to use in the > offer I could at least take that into consideration when > accepting/declining the offerless invite. We cannot discuss this without delving into the UI of the devices. I agree that you may not always want to offer video even if you have the capability. This can be handled by having default settings for use of media by your device: which media should be offered by default when you initiate an offer, and which should be accepted by default when you answer an incoming offer. Ideally it should be possible to change the defaults, and to change the settings for a given call either before the call is placed or answered, or after. Directionality is also possible. For instance, that you are willing to receive video, but not transmit by default. (Then you can decide to enable transmission after you learn who it is, or get dressed.) > Is it so that you think that the offer Bob should make should include > all supported media types, but that all of them (or configurable) should > be inactivated, and that Bob should not be alerted until Alice have > decided what media types she decided not to completely deny? After that > BoB's UA could ask Bob if he wanted to have an audio+video call, and Bob > would then only activate the audio stream in a re-INVITE, as he had a > bad-hair-day? Yeah, you seem to get the general idea. I think a well human-engineered video phone will need this kind of capability. 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 Mar 17 02:10:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK94U-00089f-T9; Fri, 17 Mar 2006 02:08:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK94S-00089a-NW for sip@ietf.org; Fri, 17 Mar 2006 02:08:24 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK94Q-0003aK-LV for sip@ietf.org; Fri, 17 Mar 2006 02:08:24 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C4C0F5E9; Fri, 17 Mar 2006 08:08:21 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 08:08:21 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 08:08:21 +0100 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] The Problem with PRACK Date: Fri, 17 Mar 2006 08:08:20 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B65@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZJZ0sQdUmBt4KFT7W864amEjm95AAKimpQ From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 17 Mar 2006 07:08:21.0206 (UTC) FILETIME=[93014F60:01C64991] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sip@ietf.org, Juha Heinanen , Brett Tate , 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 >>Is there something that would NOT work by using UPDATE instead of PRACK? > >If you mean for sending an *offer*, then UPDATE can work as well as prack, at the expense of two more messages. > >But UPDATE doesn't substitute for sending an answer to an offer received in a reliable 1xx. > >What would *not* work are UAs that are currently programmed to use PRACK to send offers. Of course. I was refering more to the RFCs/drafts that you said would have to be updated. Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 16. maaliskuuta 2006 3:48 > To: Dean Willis > Cc: Juha Heinanen; sip@ietf.org; Brett Tate; Christer Holmberg=20 > (JO/LMF) > Subject: Re: [Sip] The Problem with PRACK >=20 > Dean, >=20 > I don't doubt that we could come up with some different model for how=20 > to do each thing that would be broken by deprecating PRACK. That means > deprecating not only PRACK, but all the other RFCs and drafts that are > dependent on it. I'm not sure how many of those there are, probably=20 > not a lot, but some. Each of those things will have to either be=20 > written off as a bad idea, or else redefined using some other=20 > mechanism. I guess if they are all bad ideas then this is clearly the=20 > right way to go. If some of those are still things that people want,=20 > then that makes more work to do. >=20 > What you suggest below is a different way to do security preconditions.=20 > It could be the germ of a working scheme - or maybe it will be found=20 > to be flawed after further study. In any case it will take another=20 > cycle of draft development, attention units from ietf participants,=20 > and time at ietf meetings. Do we want that? >=20 > Paul >=20 > Dean Willis wrote: >=20 >>On Mar 15, 2006, at 5:32 PM, Paul Kyzivat wrote: >> >> >>>Consider Alice sends offerless invite to Bob. But Bob is only willing >>>to do secure calls. So Bob returns an offer in a 183 with security=20 >>>preconditions. Bob needs an answer back that releases those >=20 >=20 >>>preconditions before he is willing to ring, much less answer. >> >> >>Off-the-wall response coming. >> >>How about: >> >>Bob redirects Alice to himself, along with a precondition qualifier. =20 >>Alice satisfies the preconditions, then sends Bob a new INVITE that=20 >>indicates the aforementioned preconditions have been satisfied. >> >>-- >>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 Fri Mar 17 03:13:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKA39-0002FB-7T; Fri, 17 Mar 2006 03:11:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKA37-00029j-LG for sip@ietf.org; Fri, 17 Mar 2006 03:11:05 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKA35-0005Ng-6H for sip@ietf.org; Fri, 17 Mar 2006 03:11:05 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2H89hQ5011949; Fri, 17 Mar 2006 10:09:45 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 10:10:57 +0200 Received: from [172.21.38.152] ([172.21.38.152]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 17 Mar 2006 10:10:56 +0200 Message-ID: <441A6F0D.2080109@nokia.com> Date: Fri, 17 Mar 2006 10:10:53 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-02.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2006 08:10:56.0970 (UTC) FILETIME=[519D6AA0:01C6499A] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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, ext Cullen Jennings wrote: > On 3/14/06 11:55 AM, "Jeroen van Bemmel" wrote: > >> I have just done some basic testing on the Windows (XP) implementation of >> TCP keep-alive. >> >> I used the following code (s = a tcp socket): >> >> #include // for tcp_keepalive >> >> int val = TRUE; >> ::setsockopt( s, SOL_SOCKET, SO_DONTLINGER, (const char*) &val, >> sizeof(val) ); >> ::setsockopt( s, SOL_SOCKET, SO_KEEPALIVE, (const char*) &val, >> sizeof(val) ); >> ::setsockopt( s, IPPROTO_TCP, TCP_NODELAY, (const char*) &val, >> sizeof(val) ); >> >> tcp_keepalive settings; >> settings.onoff = 1; >> settings.keepaliveinterval = 1000; // interval of a probe when failed, in ms >> settings.keepalivetime = 60000; // every X ms, default is 2 hours >> DWORD nBytes=0; >> int r = ::WSAIoctl( s, SIO_KEEPALIVE_VALS, &settings, sizeof(settings), >> NULL, 0, &nBytes, NULL, NULL ); // succeeds, r==0 >> >> This causes the client to send a TCP keep-alive segment with SEG.SEQ = >> SND.NXT-1 as per RFC1122, containing 1 byte of garbage data (byte 00) and DF >> flag set. It sends the first probe 60 seconds after the connection has been >> idle (I only performed a TCP REGISTER over it), and repeats this every >> interval as specified. Different values give different intervals, and other >> connections are not affected. The server (a win2k machine I think) responds >> with a TCP ACK segment >> >> My conclusion: This seems usable... > agree > > Thank you. Any chance someone could try the equivalent things on some other > OS? particularly Linux and Solaris? OSX? Other versions of windows? Is this strictly an OS issue? Can you set these options via the socket APIs of, say, Java or C#? I quickly tried on Linux, using perl's Socket module (wrapper for sys/socket.h and with PHP's socket functions. Both let you enable keepalives (SO_KEEPALIVE set to true), but both failed when I tried to set TCP-level options, namely TCP_KEEPIDLE and TCP_KEEPINTVL. It could be me, or then for those languages, only socket level options are supported. If this is so, and I didn't goof on some silly thing, with PHP or perl, you'd be left with the default idle time of 2 hours, before keepalives start (in 75 second intervals). Hope this helps. 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 Mar 17 04:01:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAnk-00036Y-Ok; Fri, 17 Mar 2006 03:59:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAnj-00036T-JM for sip@ietf.org; Fri, 17 Mar 2006 03:59:15 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKAni-0006aG-4p for sip@ietf.org; Fri, 17 Mar 2006 03:59:15 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2H8x5p10833; Fri, 17 Mar 2006 03:59:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? Date: Fri, 17 Mar 2006 02:59:02 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AEE231F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? Thread-Index: AcZGEMLnAZKxbbIEEdqjXwARJEEJ/ABU9AmAAB7GdDQABQFSYABOM71XABxGKCA= From: "Samir Srivastava" To: "Cullen Jennings" , "Christer Holmberg \(JO/LMF\)" , "Hisham Khartabil" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a 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 STUN with magic binary cookie is hack too. That looks to me going back to binary protocols and defeating the purpose of text based SIP protocol. Another point "Every application protocol=20 should take of its own mess using its own primitives" . Within SIP too all headers doesn't=20 apply to all methods, we are doing this to achive the performance. So PING is lesser evil than STUN. Thx Samir -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Thursday, March 16, 2006 11:05 AM To: Srivastava, Samir [SC100:8826:EXCH]; Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? If you are going to make the new message so that it is not part of SIP, ie things like Proxy-Require are not used, then it is basically a new protocol and it sounds very similar to just doing some other new protocol over the same transport as the SIP stuff. =20 On 3/14/06 10:18 PM, "Samir Srivastava" wrote: > We cannot differentiate whether OPTIONS is for keep alive or for other > purpose without parsing it completely. It might have Require and Proxy > Require too. That was the sole purpose of dedicated new message. >=20 > How gaming protocols use STUN i.e. muxing, keep alives ? We might have > Gaming Application and SIP UA on the same physical Device. >=20 > Thx > Samir >=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, March 14, 2006 7:22 PM > To: Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org > Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN=20 > requestprocessingfaster than a SIP PING request processing? >=20 >=20 > Options would not be forwarded if it was sent to the edge proxy. >=20 >=20 > On 3/14/06 4:48 AM, "Christer Holmberg (JO/LMF)" > wrote: >=20 >>=20 >> Hi, >>=20 >> Without commenting on the "speed" issue, IF we want to use a SIP=20 >> based >=20 >> solution I would prefear a dedicated one, instead of re-using OPTIONS. >>=20 >> Like I said earlier, IF the edge proxy "understands" the mechanism,=20 >> and IF it knows the request does not need to be forwarded, it can=20 >> choose to terminate it. Yes, it's b2bua behaviour, but still. I do=20 >> not >=20 >> want a solution that forces me to overload the rest of the network=20 >> with the keep-alive requests - no matter what mechanism is used - and >> therefor OPTIONS is not a good solution, because since OPTIONS would=20 >> also be used for non-keep-alive purposes it would always have to be > forwarded. >>=20 >> Another solution, as I mentioned earlier, would be that the=20 >> keep-alives are addressed to the edge proxy (or whatever entity on=20 >> the >=20 >> other side of the NAT). Then it would be "normal SIP", without any > b2bua behavior. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 12. maaliskuuta 2006 22:09 >> To: Hisham Khartabil; sip@ietf.org >> Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request=20 >> processingfaster than a SIP PING request processing? >>=20 >>=20 >> You results don't look right to me. I can't really test very well on=20 >> my notebook computer but with STUN on a apple powerbook I am getting=20 >> 16,000 TPS at about 30% CPU. Who knows what I could get with an intel >> processor >> :-) Your results look like 6 to 10k TPS. When people quote ms I never >> have any clue if they are including the kernel time, it it is a=20 >> latency or what. The number we need here is aggregate throughput, not >> latency so actual transactions per second on some suitable box might=20 >> be the easies to compare. >> Similarly, the rates of OPTIONS also looked fairly slow so perhaps I=20 >> just don't get what you are measuring. >>=20 >> Ignoring that, when I look at the code, I can't see any particular=20 >> reason that the speed of PING would not be roughly the same as STUN. >> The problem is this violates RFC 3261 in so many ways that you can=20 >> barely make a list of them all. Once you do the processing to make=20 >> this consistent with existing things, the performance will drop=20 >> significantly >> - my guess is that it would drop to roughly the same rate as OPTION. >>=20 >>=20 >> On 3/6/06 10:02 AM, "Hisham Khartabil" >> wrote: >>=20 >>> I promised to come back with hard real numbers on how long it will=20 >>> take for a server to process and STUN request vs a SIP PING request >>>=20 >>> Myth: processing a STUN request is 10 to 100 times faster than a SIP >>> PING request >>>=20 >>> Assumptions: - SIP PING request is processed early in the stack and >>> bypasses any unnecessary validations. >>> - SIP PING response carries in the contact header the >>> IP address and port as appears in the IP packet (source IP and port). >>>=20 >>> We implemented the PING request as described above in the=20 >>> reSIProcate >=20 >>> stack. Attached you will find the c++ file where the changes were >> made. >>> STUN was already implemented in the reSIProcate stack and used as is. >>>=20 >>> Below you will see the findings: >>>=20 >>> STUN request processing: 0.15 - 0.2 ms SIP PING request processing: >>> 0.1 - 0.2 ms SIP OPTIONS request: 7 ms SIP REGISTER request: 7 ms >>>=20 >>> The measurement was taken between the time a request appeared on=20 >>> ethereal and its response appearing on ethereal. Average was taken=20 >>> manually. >>>=20 >>> As you can see, SIP PING requests were sometimes faster to process=20 >>> that STUN requests, but never slower. Actually the SIP PING requests >>> on average were faster to process. >>>=20 >>> Myth Busted!!!! :) >>>=20 >>> Regards, >>> Hisham >>> P.S. It took 15 mins to modify the sip stack to do the PING response. >>>=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 > _______________________________________________ > 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 Mar 17 04:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBaF-00059U-GK; Fri, 17 Mar 2006 04:49:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBaD-00059P-4h for sip@ietf.org; Fri, 17 Mar 2006 04:49:21 -0500 Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKBaB-0008Ox-IA for sip@ietf.org; Fri, 17 Mar 2006 04:49:21 -0500 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.36 ; Fri, 17 Mar 2006 10:49:12 +0100 Content-class: urn:content-classes:message Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Mar 2006 10:49:16 +0100 Message-ID: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? Thread-Index: AcZGEMLnAZKxbbIEEdqjXwARJEEJ/ABU9AmAAB7GdDQABQFSYABOM71XABxGKCAAAfPOgA== From: "Christian Jansson" To: "Samir Srivastava" , "Cullen Jennings" , "Christer Holmberg (JO/LMF)" , "Hisham Khartabil" , X-Spam-Score: 1.5 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 > Samir wrote: >STUN with magic binary cookie is hack too.That looks to me going back >to binary protocols and defeating the purpose of text based SIP >protocol.=20 So in principal you rather have something that is human readable than something that works better in reality? >Another point "Every application protocol >should take of its own mess using its own primitives" . You mean we should for example also use SIP instead of DNS, DHCP, and RTP? In general I think it is better to use a tool that is designed for the problem. >Within SIP too all headers doesn't >apply to all methods, we are doing this to achive the performance. SIP parsing and performance are not optimized, that is a fact. SIP and human readability on the other hand... but who cares. >So PING is lesser evil than STUN. If PING was SIP I would have no problem with it, but as it is defined right now PING is not SIP even though the draft wants it to be. And I do not think we should standardize things that are plain wrong just because it for the moment does not seem to introduce any enormous problems. I think we have 3 real options: 1. Double CRLF 2. A new real SIP method 3. STUN Bad ideas: 4. Using OPTIONS is a bad idea as it has another purpose, and adding new method would cost us nothing and it would be very clear what was going on. 5. Using PING as it is being discussed right now is not an option as long as it is not SIP as it claims to be. I do not want to see any more discussions of non-SIP things that just looks like SIP anymore. / Christian Jansson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 17 07:38:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEBx-0006FO-SS; Fri, 17 Mar 2006 07:36:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEBw-0006FJ-M0 for sip@ietf.org; Fri, 17 Mar 2006 07:36:28 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKEBv-0004rb-6r for sip@ietf.org; Fri, 17 Mar 2006 07:36:28 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2HCaJ9a018304; Fri, 17 Mar 2006 14:36:22 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 14:36:14 +0200 Received: from [172.21.38.152] ([172.21.38.152]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 17 Mar 2006 14:36:14 +0200 Message-ID: <441AAD3C.2070705@nokia.com> Date: Fri, 17 Mar 2006 14:36:12 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Aki Niemi Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-02.txt References: <441A6F0D.2080109@nokia.com> In-Reply-To: <441A6F0D.2080109@nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2006 12:36:14.0025 (UTC) FILETIME=[60EB4390:01C649BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ext Cullen Jennings , "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 One more thing, Symbian only seems to support TCP keepalives with global idle and probe intervals, and not per-connection basis. Meaning, something else is still needed there. Cheers, Aki ext Aki Niemi wrote: > Hi, > > ext Cullen Jennings wrote: >> On 3/14/06 11:55 AM, "Jeroen van Bemmel" wrote: >> >>> I have just done some basic testing on the Windows (XP) implementation of >>> TCP keep-alive. >>> >>> I used the following code (s = a tcp socket): >>> >>> #include // for tcp_keepalive >>> >>> int val = TRUE; >>> ::setsockopt( s, SOL_SOCKET, SO_DONTLINGER, (const char*) &val, >>> sizeof(val) ); >>> ::setsockopt( s, SOL_SOCKET, SO_KEEPALIVE, (const char*) &val, >>> sizeof(val) ); >>> ::setsockopt( s, IPPROTO_TCP, TCP_NODELAY, (const char*) &val, >>> sizeof(val) ); >>> >>> tcp_keepalive settings; >>> settings.onoff = 1; >>> settings.keepaliveinterval = 1000; // interval of a probe when failed, in ms >>> settings.keepalivetime = 60000; // every X ms, default is 2 hours >>> DWORD nBytes=0; >>> int r = ::WSAIoctl( s, SIO_KEEPALIVE_VALS, &settings, sizeof(settings), >>> NULL, 0, &nBytes, NULL, NULL ); // succeeds, r==0 >>> >>> This causes the client to send a TCP keep-alive segment with SEG.SEQ = >>> SND.NXT-1 as per RFC1122, containing 1 byte of garbage data (byte 00) and DF >>> flag set. It sends the first probe 60 seconds after the connection has been >>> idle (I only performed a TCP REGISTER over it), and repeats this every >>> interval as specified. Different values give different intervals, and other >>> connections are not affected. The server (a win2k machine I think) responds >>> with a TCP ACK segment >>> >>> My conclusion: This seems usable... >> agree >> >> Thank you. Any chance someone could try the equivalent things on some other >> OS? particularly Linux and Solaris? OSX? Other versions of windows? > > Is this strictly an OS issue? Can you set these options via the socket > APIs of, say, Java or C#? > > I quickly tried on Linux, using perl's Socket module (wrapper for > sys/socket.h and with PHP's socket functions. Both let you enable > keepalives (SO_KEEPALIVE set to true), but both failed when I tried to > set TCP-level options, namely TCP_KEEPIDLE and TCP_KEEPINTVL. It could > be me, or then for those languages, only socket level options are > supported. If this is so, and I didn't goof on some silly thing, with > PHP or perl, you'd be left with the default idle time of 2 hours, before > keepalives start (in 75 second intervals). > > Hope this helps. > > 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 From sip-bounces@ietf.org Fri Mar 17 07:57:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEUz-0006r3-4n; Fri, 17 Mar 2006 07:56:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEUw-0006qV-OV for sip@ietf.org; Fri, 17 Mar 2006 07:56:07 -0500 Received: from web52803.mail.yahoo.com ([206.190.48.246]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FKEUv-0005Qp-CT for sip@ietf.org; Fri, 17 Mar 2006 07:56:06 -0500 Received: (qmail 28368 invoked by uid 60001); 17 Mar 2006 12:56:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ojhacpprjdAqoLs0ZE3d3O114USkpZOCE+ccEORWL1PrFfF1a/buY5mqisQzQscvlY+yPljnH2tdgsbh//YXpGiLz4JiDtl9BpB8S811S/pKGHu9cy3050+HAtZl7fLqyXCVeuKq2ecUl/HPdMleRePgEVuz49nmTQdQHSDlfhs= ; Message-ID: <20060317125601.28366.qmail@web52803.mail.yahoo.com> Received: from [47.165.147.102] by web52803.mail.yahoo.com via HTTP; Fri, 17 Mar 2006 04:56:01 PST Date: Fri, 17 Mar 2006 04:56:01 -0800 (PST) From: Fatih "Eyüp" NAR To: simple@ietf.org, sip@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Sip] whose preference comes first:RFC 3841 or Terminator's CPL Rules X-BeenThere: sip@ietf.org X-Mailman-Version: 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 trying to identify; "what Proxy Shall do in case received session included Originator's Preference (ex:Request-Disposition=No-Fork) inside and Proxy also has Terminator's CPL Rules (ex:it says Fork to call to Home-Office-Mobile at the same time) ? I couln't see any explanation (i.e. RFC) about that till now anywhere , can you help me on this please? regards fatih e. nar __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 17 08:40:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKF9a-00078n-Kx; Fri, 17 Mar 2006 08:38:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKF9Z-00078e-HV for sip@ietf.org; Fri, 17 Mar 2006 08:38:05 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKF9Y-0006ya-Bk for sip@ietf.org; Fri, 17 Mar 2006 08:38:05 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k2HDbxsj075471; Fri, 17 Mar 2006 08:38:03 -0500 (EST) From: "Brett Tate" To: "'Rohan Mahy'" Subject: RE: [Sip] The Problem with PRACK Date: Fri, 17 Mar 2006 08:39:04 -0500 Message-ID: <000001c649c8$28b9a620$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <953beacc0603161402t36f6db93g8b7f936009d6b12f@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Rohan, Thanks for the clarity. > - require RSeq to start at 1 The change sounds good if the following changes are also accepted. = Without the following changes, there might be poor interaction between UACs supporting and UASs not supporting the requirement; thus a new = option-tag might be needed. > - only acknowledge the most recent provisional. > if the UAS wants to send as new provisional that > completely replaces a previous one it can send > immediately. if the UAS wants to send a new > provisional but wants acknowledgement of a previous > one, it has to wait for the PRACK. The change sounds good. Some UACs already act this way because of misinterpretation of rfc3262's "one higher" text or they implemented = drafts and haven't became compliant to rfc3262. Are there currently UASs which don't queue 1xx's and expect the UACs to ignore 1xx containing two higher RSeq as discussed in rfc3262 section 4? = If so, the mentioned new option-tag would likely be needed. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 17 08:59:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKFSi-0006CP-1v; Fri, 17 Mar 2006 08:57:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKFSg-0006CK-K7 for sip@ietf.org; Fri, 17 Mar 2006 08:57:50 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKFSg-0007ds-81 for sip@ietf.org; Fri, 17 Mar 2006 08:57:50 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IW900H01YN8CG@siemenscomms.co.uk> for sip@ietf.org; Fri, 17 Mar 2006 13:54:44 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IW900G3CYMDHT@siemenscomms.co.uk>; Fri, 17 Mar 2006 13:54:13 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Mar 2006 13:56:59 +0000 Content-return: allowed Date: Fri, 17 Mar 2006 13:56:47 +0000 From: "Elwell, John" Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? To: Christian Jansson , Samir Srivastava , Cullen Jennings , "Christer Holmberg (JO/LMF)" , Hisham Khartabil , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667086B028A@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Christian, I agree, and I would also eliminate option 2, because it seems clear from evidence presented to date that any SIP method that is conformant with normal SIP rules will have a significant impact on scalability. John > -----Original Message----- > From: Christian Jansson [mailto:christian.jansson@hotsip.com] > Sent: 17 March 2006 09:49 > To: Samir Srivastava; Cullen Jennings; Christer Holmberg > (JO/LMF); Hisham Khartabil; sip@ietf.org > Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN > requestprocessingfaster than a SIP PING request processing? > > > Samir wrote: > >STUN with magic binary cookie is hack too.That looks to me going back > >to binary protocols and defeating the purpose of text based SIP > >protocol. > > So in principal you rather have something that is human readable than > something that works better in reality? > > > >Another point "Every application protocol > >should take of its own mess using its own primitives" . > > You mean we should for example also use SIP instead of DNS, DHCP, and > RTP? In general I think it is better to use a tool that is > designed for > the problem. > > >Within SIP too all headers doesn't > >apply to all methods, we are doing this to achive the performance. > > SIP parsing and performance are not optimized, that is a fact. SIP and > human readability on the other hand... but who cares. > > >So PING is lesser evil than STUN. > > If PING was SIP I would have no problem with it, but as it is defined > right now PING is not SIP even though the draft wants it to > be. And I do > not think we should standardize things that are plain wrong > just because > it for the moment does not seem to introduce any enormous problems. > > I think we have 3 real options: > 1. Double CRLF > 2. A new real SIP method > 3. STUN > > Bad ideas: > 4. Using OPTIONS is a bad idea as it has another purpose, and > adding new > method would cost us nothing and it would be very clear what was going > on. > 5. Using PING as it is being discussed right now is not an option as > long as it is not SIP as it claims to be. I do not want to > see any more > discussions of non-SIP things that just looks like SIP anymore. > > / Christian Jansson > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 17 10:07:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGW7-00053M-JJ; Fri, 17 Mar 2006 10:05:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGW6-00053H-11 for sip@ietf.org; Fri, 17 Mar 2006 10:05:26 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKGW5-0001TC-JB for sip@ietf.org; Fri, 17 Mar 2006 10:05:26 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2HF3qmO024201; Fri, 17 Mar 2006 17:03:57 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 17:05:12 +0200 Received: from [172.21.38.152] ([172.21.38.152]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 17 Mar 2006 17:05:12 +0200 Message-ID: <441AD027.6030801@nokia.com> Date: Fri, 17 Mar 2006 17:05:11 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2006 15:05:12.0764 (UTC) FILETIME=[30D297C0:01C649D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] Comments to sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 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've got a couple of comments on the -02 version: 1) I understand the need to configure the outbound proxy sets, but I don't like the fact that the registrar URIs would also be configured (as is mentioned in 3.3.). I've seen enough user agent configurations asking for the registrar URI (when the AoR is really all you need), that I would like to discourage that behavior rather than encourage it. Human users' ability to configure things is limited to perhaps an address and a password at most, and well, automagic configuration doesn't really work in real life. How about saying that the registrar domain returns the registrar URIs in a 300 to REGISTER. Of course, in certain "rare" setups, the proxy set could also be returned in a 305. This would be optional, of course, and those domains that want to make things difficult could still rely on configuration. :) 2) In 4.5: If the number of consecutive-failures is large enough that the maximum of 1800 seconds is reached, the UA will keep trying forever with a random time between 900 and 1800 seconds between the attempts. You don't really mean "forever" here, right? 3) In 5.3: Note that techniques to ensure that mid-dialog requests are routed over an existing flow are out of scope and therefore not part of this specification. How can this work then with symmetric NATs? I mean, a BYE from the other end would fail, wouldn't it? So shouldn't the edge proxy always record route? This is only an issue with UDP, btw. 4) The draft mentions rport, but doesn't say much about how rport and sip-outbound work together. Actually, i think it would be simple and elegant for TCP flows to use a combination of TCP keepalives and rport. Wouldn't that work teh same as with STUN? In fact, it might be wise to separate the keepalive behavior of TCP and UDP a little better. In some sense, I agree with a previous post in that perhaps sip-outbound-tcp and sip-outbound-udp need not be that tied together in terms of keepalives and NAT binding detection. Remind me again why does the UA need to find out the NAT address/port with TCP? 5) About the open issues: Do we want to include the Double CRLF keep alive option? Might as well, as an option to TCP keepalives, perhaps. Are thre any deployments that could use Algorithm 1 and if not can we remove it? Don't remove. We should change syntax from "sip-stun" to "keep-alive=sip-stun". Looks good. Overall, nice draft. 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 Mar 17 11:53:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIAO-0000vr-5Q; Fri, 17 Mar 2006 11:51:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIAL-0000vg-UY for sip@ietf.org; Fri, 17 Mar 2006 11:51:05 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKIAL-0005FF-I7 for sip@ietf.org; Fri, 17 Mar 2006 11:51:05 -0500 Received: (from apache@localhost) by figas.ekabal.com (8.11.6/8.11.6) id k2HGotE18610; Fri, 17 Mar 2006 08:50:55 -0800 From: Rohan Mahy X-Authentication-Warning: figas.ekabal.com: apache set sender to rohan@localhost using -f Received: from 12.151.41.2 (SquirrelMail authenticated user rohan); by figas.ekabal.com with HTTP; Fri, 17 Mar 2006 08:50:55 -0800 (PST) Message-ID: <39229.12.151.41.2.1142614255.squirrel@12.151.41.2> In-Reply-To: <441AD027.6030801@nokia.com> References: <441AD027.6030801@nokia.com> Date: Fri, 17 Mar 2006 08:50:55 -0800 (PST) To: "Aki Niemi" User-Agent: SquirrelMail/1.4.3a-1 X-Mailer: SquirrelMail/1.4.3a-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy Subject: [Sip] Re: Comments to sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 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've got a couple of comments on the -02 version: Thanks Aki. > 1) I understand the need to configure the outbound proxy sets, but I > don't like the fact that the registrar URIs would also be configured (as > is mentioned in 3.3.). > > I've seen enough user agent configurations asking for the registrar URI > (when the AoR is really all you need), that I would like to discourage > that behavior rather than encourage it. Human users' ability to > configure things is limited to perhaps an address and a password at > most, and well, automagic configuration doesn't really work in real life. > > How about saying that the registrar domain returns the registrar URIs in > a 300 to REGISTER. Of course, in certain "rare" setups, the proxy set > could also be returned in a 305. This would be optional, of course, and > those domains that want to make things difficult could still rely on > configuration. :) The problem with using a 3xx is that we want the semantics to be that you register with all the provided outbound addresses. I agree the user should need less to get started though. Jonathan actually suggested using a separate (optional) type of SRV lookup to find your outbound proxy set. > 2) In 4.5: > > If the number of consecutive-failures is large enough that the > maximum of 1800 seconds is reached, the UA will keep trying forever > with a random time between 900 and 1800 seconds between the attempts. > > You don't really mean "forever" here, right? Yeah, I don't like forever or infinite either. How about "indefinitely"? > 3) In 5.3: > > Note that techniques to ensure that mid-dialog requests are routed > over an existing flow are out of scope and therefore not part of this > specification. > > How can this work then with symmetric NATs? I mean, a BYE from the other > end would fail, wouldn't it? So shouldn't the edge proxy always record > route? This is only an issue with UDP, btw. The edge proxy needs to do something, but we don't specify what. In the normal case, the edge proxy can just record-route and that is sufficient. Folks that want to do failover or per-dialog state blobs may need to do something extra. The community has already figured out how to do this, so Additional normative language in *this* spec is more likely to irritate rather than help an implementor. > 4) The draft mentions rport, but doesn't say much about how rport and > sip-outbound work together. Actually, i think it would be simple and > elegant for TCP flows to use a combination of TCP keepalives and rport. > Wouldn't that work teh same as with STUN? > > In fact, it might be wise to separate the keepalive behavior of TCP and > UDP a little better. In some sense, I agree with a previous post in that > perhaps sip-outbound-tcp and sip-outbound-udp need not be that tied > together in terms of keepalives and NAT binding detection. Remind me > again why does the UA need to find out the NAT address/port with TCP? First a disclaimer. I DONT CARE ANYMORE which keepalive technique we use for TCP. Using the OS-provided TCP keepalives is insufficient (too short). Using double CRLF would work and STUN would both work. The argument in favor of STUN is that you would do the same thing over both transports so it would be only one thing to implement. I will point out however that the main motivation for outbound is to make TCP and TLS work, so folks may not implement outbound support for TCP and UDP at the same time. > 5) About the open issues: > > Do we want to include the Double CRLF keep alive option? > > Might as well, as an option to TCP keepalives, perhaps. > > Are thre any deployments that could use Algorithm 1 and if not can we > remove it? > > Don't remove. > > We should change syntax from "sip-stun" to "keep-alive=sip-stun". > > Looks good. > > Overall, nice draft. thanks much, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 17 14:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKEp-0006fB-EP; Fri, 17 Mar 2006 14:03:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKEo-0006f6-I7 for sip@ietf.org; Fri, 17 Mar 2006 14:03:50 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKKEn-0001XT-7R for sip@ietf.org; Fri, 17 Mar 2006 14:03:50 -0500 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2HJ49lp004651 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Mar 2006 13:04:10 -0600 In-Reply-To: <441AD027.6030801@nokia.com> References: <441AD027.6030801@nokia.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F5A6AB8-381D-48C0-BF20-3ABE6B3DA9BF@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Comments to sip-outbound Date: Fri, 17 Mar 2006 13:03:43 -0600 To: Aki Niemi X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 17, 2006, at 9:05 AM, Aki Niemi wrote: > > I've seen enough user agent configurations asking for the registrar > URI > (when the AoR is really all you need), that I would like to discourage > that behavior rather than encourage it. Human users' ability to > configure things is limited to perhaps an address and a password at > most, and well, automagic configuration doesn't really work in real > life. > Hmm. The address of my POP server cannot be deduced from my email address, yet I seem to be able to configure my email client, as do most users. I've also found the UAs that fail to different between registrar address and AOR to be unusable in many situations that have cropped up with various experimental and demonstration configurations. Quite often, I really DO want my UA to send its REGISTER requests to a destination that is not DNS-congruent with the domain part of my AOR. This is especially common if the registrar is dual-homed, with one leg in a private network and one leg in a public network. The UA, also on the private network, needs to send its REGISTER requests to the "private" side of the registrar, whereas its the "public" side of the registrar that gets the DNS pointer. -- 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 Mar 17 14:17:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKQH-0006b2-Cj; Fri, 17 Mar 2006 14:15:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKQG-0006au-1z for sip@ietf.org; Fri, 17 Mar 2006 14:15:40 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKKQE-0002A8-QX for sip@ietf.org; Fri, 17 Mar 2006 14:15:40 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k2HJFXxY009657; Fri, 17 Mar 2006 14:15:37 -0500 (EST) From: "Brett Tate" To: "'Christer Holmberg \(JO/LMF\)'" Subject: RE: [Sip] The Problem with PRACK Date: Fri, 17 Mar 2006 14:16:39 -0500 Message-ID: <001901c649f7$5164fb40$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B60@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 > > - only acknowledge the most recent provisional. > > if the UAS wants to send as new provisional that > > completely replaces a previous one it can send > > immediately. if the UAS wants to send a new > > provisional but wants acknowledgement of a previous > > one, it has to wait for the PRACK. > =09 > > I assume RSeq would still be checked so UAC is > > able to notice out of order provisional responses. >=20 > [CHH] What to you mean by "replace a provisional response"??? My interpretation is that the UAC no longer has to follow the rfc3262 requirement to drop 1xx responses which incremented by more than 1. And = if the contents of the prior 1xx must not be ignored, the UAS must queue subsequent 1xx until prior one is acknowledged. The text basically = shifts the MUST burden of ensuring no ignored 1xx's to UAS instead of the UAC. > [CHH] and I DO think we should get rid > of the rule by mandating an offer in the first=20 > rel18x (if the INV didn't carry an offer). (I assume "by" was not intentional within the above text.) This is a common non compliance because of vendors deploying draft = versions of the 100rel functionality. And vendors which supported 100rel and = haven't implemented/upgraded to rfc3262 are currently required to deactivate = 100rel to avoid non compliance to offer/answer usages. =20 I agree that the MUST should be reduce to a SHOULD. I think the text = was added for clipping and 183 type reasons; and there are other reasons for = it. The functionality is useful; however it disables the UAS from reliably sending a 18x unless able/willing to adhere to the offer/answer requirements. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 17 15:26:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLUt-0001p8-Fa; Fri, 17 Mar 2006 15:24:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLUr-0001oy-Ms for sip@ietf.org; Fri, 17 Mar 2006 15:24:29 -0500 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKLUr-0004WR-B7 for sip@ietf.org; Fri, 17 Mar 2006 15:24:29 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2HKOMt13779; Fri, 17 Mar 2006 15:24:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? Date: Fri, 17 Mar 2006 14:24:20 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AEE2A69@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaster than a SIP PING request processing? Thread-Index: AcZGEMLnAZKxbbIEEdqjXwARJEEJ/ABU9AmAAB7GdDQABQFSYABOM71XABxGKCAAAfPOgAAStPBA From: "Samir Srivastava" To: "Christian Jansson" , "Cullen Jennings" , "Christer Holmberg \(JO/LMF\)" , "Hisham Khartabil" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Inline below. Thx Samir -----Original Message----- From: Christian Jansson [mailto:christian.jansson@hotsip.com]=20 Sent: Friday, March 17, 2006 1:49 AM To: Srivastava, Samir [SC100:8826:EXCH]; Cullen Jennings; Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN requestprocessingfaster than a SIP PING request processing? > Samir wrote: >STUN with magic binary cookie is hack too.That looks to me going back=20 >to binary protocols and defeating the purpose of text based SIP=20 >protocol. So in principal you rather have something that is human readable than something that works better in reality? SS>> If you want something works better i.e. real high performance. Invent something similar to=20 H.323 with SIP features and have fun. Why we have all XML extensions for presence and SAML=20 etc, use ASN.1 ? SIP is ASCII based protocol. So we better stick to that. We wanted to find a solution within SIP boundaries. More below. >Another point "Every application protocol should take of its own mess=20 >using its own primitives" . You mean we should for example also use SIP instead of DNS, DHCP, and RTP? In general I think it is better to use a tool that is designed for the problem. SS>> I think I wasn't explaintary enough on this. Every protocol plays its own role for which=20 they are designed. You streteched too far to include DNS, DHCP etc... My position was "SIP port NAT binding should be refreshed by SIP. There may be other STUN clients too. If they also see the same problem what we are going to do." That was the reason for my related=20 question earlier for online gaming. How on line gaming protocols use STUN and what they do=20 for muxing and keep alive. This will give us real life experience of the same problem faced by another application protocol. We might have SIP UA and Gaming Application running=20 simulatenously on the same physical device. Whether there will be always multiple STUN=20 clients sitting on different ports, or we will be doing muxing there too ? Any guidelines ? Any gaming protocol expert on the list to share the experience ? =20 With SIP PING method, we can easily find out the traffic stats from SIP MIB for overload and congestion. How we will find stats of STUN Keep alive load in a out-of-band manner ? >Within SIP too all headers doesn't >apply to all methods, we are doing this to achive the performance. SIP parsing and performance are not optimized, that is a fact. SIP and human readability on the other hand... but who cares. SS>> You can create a tool to do binary to ASCII (or whatever interpretation you want ) conversion. Earlier you were asking for performance, here you don't care.=20 Can somebody present me an application for Require and Proxy-Require for PING which cannot be done with existing OPTIONS. If you need to find capabilities etc, use existing OPTIONS with=20 Require and Proxy-Require. Purpose of PING is to do heart beat only. I will reiterate in the purist sense it might looks like SIP, but it is better than pure binary cookie and leave the floor for community to decide. >So PING is lesser evil than STUN. If PING was SIP I would have no problem with it, but as it is defined right now PING is not SIP even though the draft wants it to be. And I do not think we should standardize things that are plain wrong just because it for the moment does not seem to introduce any enormous problems. I think we have 3 real options: 1. Double CRLF 2. A new real SIP method 3. STUN Bad ideas: 4. Using OPTIONS is a bad idea as it has another purpose, and adding new method would cost us nothing and it would be very clear what was going on. 5. Using PING as it is being discussed right now is not an option as long as it is not SIP as it claims to be.=20 I do not want to see any more discussions of non-SIP things that just looks like SIP anymore. SS>> You are too quick in stopping the discussion while discussing the merits / demerits . / Christian Jansson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 17 15:49:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLr3-0006j4-CL; Fri, 17 Mar 2006 15:47:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLr2-0006iz-1b for sip@ietf.org; Fri, 17 Mar 2006 15:47:24 -0500 Received: from m6f095e42.tmodns.net ([66.94.9.111] helo=svcstsnq07.hotspot.t-mobile.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKLr1-0004qF-L8 for sip@ietf.org; Fri, 17 Mar 2006 15:47:24 -0500 Received: from [10.224.12.59] (59.12.224.10.in-addr.arpa [10.224.12.59]) by svcstsnq07.hotspot.t-mobile.com (8.12.10+Sun/8.12.10) with ESMTP id k2HKlFVA005213; Fri, 17 Mar 2006 12:47:15 -0800 (PST) Message-ID: <441B2052.4070500@ntt-at.com> Date: Fri, 17 Mar 2006 12:47:14 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] Re: Outbound and GRUU, References: <440F199F.2060007@alcatel.fr> <14203.12.151.41.2.1141859464.squirrel@12.151.41.2> <441137EF.50102@alcatel.fr> <0c50f5059ed82a8f70483a83e1e551d6@ekabal.com> In-Reply-To: <0c50f5059ed82a8f70483a83e1e551d6@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0 adultscore=0 adjust=0 reason=mlx engine=3.1.0-06031500 definitions=3.0.0-06031713 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by svcstsnq07.hotspot.t-mobile.com id k2HKlFVA005213 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: fluffy@cisco.com, 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 Rohan; Actually I find this really confusing. And I do apologized if my=20 question was answered in last couple of days as I lost mails from the last few days. GRUU's example shows the GRUU URI as user@domain.com;opaque=3D{instance-id}. =20 The way outbound is indicating a global routable address with instance=20 mapping information is user@domain.com;sip.instance=3D{instance-id}. *Although the example is for REGISTER/200 OK, section 4.1 specifies for UA to include the "+sip.instance" with SHOULD strength. I might be looking over something, or it could simply be my ignorance but they both seem to address the property GRUU is trying to=20 satisfy. Although with GRUU you could generate the user part and allows for an address with an anonymous characteristic and globally routable at the same time. Considering there is a need to support the handling and usage of the instance id(or something equivalent that identifies the instance) on both Proxy and UA in almost equivalent fashion, I don't understand why you made the outbound independent of gruu? Regards Shida Schubert Rohan Mahy wrote: > Hi Thomas, > > FYI: The latest outbound draft does not depend on GRUU. > > Sorry, but there is no good reason to introduce a second solution. =20 > The first solution is general and the second one is fully covered by=20 > the first. The outbound draft is already long enough, and creating=20 > and using an instance-id is not a burden. Generating one from your=20 > MAC address takes less than lines of code. Then you just include it=20 > in your registers. > > thanks, > -rohan > > On Mar 10, 2006, at 0:25, Thomas.Levy@alcatel.fr wrote: >> Hi Rohan, >> >> You could still have multiple flows without using an instance id. >> In fact, i think that the current version of the draft is confusing=20 >> because a reader may believe that the isntance id is used for routing=20 >> the messages to the UA. >> My opinion is that it could help understanding the Outbound solution=20 >> is there were 2 alternative solutions described in the document: >> One solution without instance id and GRUU (applicable only for AOR=20 >> with a single instance) >> The full (actual) solution with instance id and GRUU (applicable in=20 >> all the other cases) >> >> Any comment about that? >> >> Thomas >> Rohan Mahy a =E9crit : >> >>> Hi Thomas, >>> >>> The instance ID is required so that the proxy can tell it is dealing=20 >>> with >>> the same UA instance. It doesn't matter if in a real deployment you=20 >>> might >>> only have one instance. Remember that with outbound you are=20 >>> encouraged to >>> use multiple flows, all with the same instance id. >>> >>> Outbound solves a general problem. Even if an instance id might not = be >>> needed in a specific use case, it does not hurt anything to include i= t. >>> >>> hope this helps. >>> thanks, >>> -rohan >>> >>> >>> >>> >>>> Cullen and Rohan, >>>> >>>> Could you provide explanations on relation between Outbound and GRUU. >>>> In fact, I didn't follow whole the threads concerning the Outbound >>>> draft, perhaps it may explain my question. >>>> However, could you answer the following points: >>>> In my understanding, GRUU is useful when an AOR may be registered >>>> simultaneously on multiple UA instances. >>>> However, the scope (and requirements) from Outbound seem different. >>>> So, what are the motivations for making outbound fully dependent fro= m >>>> GRUU? >>>> For instance, in my opinion, a user registered on a natted UA could=20 >>>> use >>>> outbound (and thus have a persistent connection with its proxy)=20 >>>> without >>>> having an instance ID. >>>> Why is it mandatory for a UA to have an Instance ID (as explained in >>>> section 4.1) for outbound? >>>> >>>> Thanks for your help. >>>> >>>> Thomas LEVY >>>> >>>> >>> >>> >>> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 17 16:11:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMCk-00064A-Lr; Fri, 17 Mar 2006 16:09:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMCi-000643-Tm for sip@ietf.org; Fri, 17 Mar 2006 16:09:48 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMCi-0005ut-KQ for sip@ietf.org; Fri, 17 Mar 2006 16:09:48 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 17 Mar 2006 13:09:50 -0800 X-IronPort-AV: i="4.03,105,1141632000"; d="scan'208"; a="1785980496:sNHT34185928" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2HL9k1j005707; Fri, 17 Mar 2006 13:09:46 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Mar 2006 21:09:46 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 17 Mar 2006 13:09:47 -0800 Subject: Re: [Sip] Comments to sip-outbound From: Cullen Jennings To: Dean Willis , Aki Niemi Message-ID: Thread-Topic: [Sip] Comments to sip-outbound Thread-Index: AcZKBx7iXZl8PLX6EdqAeQARJEEJ/A== In-Reply-To: <1F5A6AB8-381D-48C0-BF20-3ABE6B3DA9BF@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "sip@ietf.org" , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 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 think that 95% of people are going to want to *not* configure any of this or the 500 other things a UA allows you to configure. That is why I think the configuration framework is so key to get done soon and make simple. On 3/17/06 11:03 AM, "Dean Willis" wrote: > > On Mar 17, 2006, at 9:05 AM, Aki Niemi wrote: > >> >> I've seen enough user agent configurations asking for the registrar >> URI >> (when the AoR is really all you need), that I would like to discourage >> that behavior rather than encourage it. Human users' ability to >> configure things is limited to perhaps an address and a password at >> most, and well, automagic configuration doesn't really work in real >> life. >> > > > Hmm. The address of my POP server cannot be deduced from my email > address, yet I seem to be able to configure my email client, as do > most users. > > I've also found the UAs that fail to different between registrar > address and AOR to be unusable in many situations that have cropped > up with various experimental and demonstration configurations. Quite > often, I really DO want my UA to send its REGISTER requests to a > destination that is not DNS-congruent with the domain part of my AOR. > This is especially common if the registrar is dual-homed, with one > leg in a private network and one leg in a public network. The UA, > also on the private network, needs to send its REGISTER requests to > the "private" side of the registrar, whereas its the "public" side of > the registrar that gets the DNS pointer. > > -- > 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 Mar 17 16:17:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMIT-0004M5-Rp; Fri, 17 Mar 2006 16:15:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMIS-0004M0-EX for sip@ietf.org; Fri, 17 Mar 2006 16:15:44 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMIR-000644-5l for sip@ietf.org; Fri, 17 Mar 2006 16:15:44 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Mar 2006 13:15:42 -0800 X-IronPort-AV: i="4.03,105,1141632000"; d="scan'208"; a="1785983279:sNHT33050926" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2HLFfYg021626; Fri, 17 Mar 2006 13:15:42 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Mar 2006 21:15:39 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 17 Mar 2006 13:15:40 -0800 Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 From: Cullen Jennings To: Dean Willis , Hans Persson Message-ID: Thread-Topic: [Sip] SBCs and draft-ietf-sip-identity-06 Thread-Index: AcZKB/FJMBDlOLX7EdqAeQARJEEJ/A== In-Reply-To: <377194C9-FFFB-4737-982E-846B3B4687BC@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 3/16/06 1:02 PM, "Dean Willis" wrote: >> ons 2006-03-15 klockan 16:36 -0600 skrev Dean Willis: >> >>> I believe it's an assertion that the call came from fluffy@cisco.com >>> signed not by cisco.com but by ingate.com. >> >> How do I make such an assertion within the framework of Identity? >> As far >> as I can tell, a UA compliant with identity-06 will reject such a >> request since the domain of the From header does not match the >> domain of >> the certificate of the signer. Or am I misunderstanding what you mean? >> > > I didn't say it actually worked. That's part of the problem with B2BUAs. > > -- You wouldn't have the UA check the identity. It delegated that job to the B2BUA when it asked the B2BUA to act on it's behalf. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 17 16:53:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMqt-00009t-RE; Fri, 17 Mar 2006 16:51:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMqs-00009o-Tt for sip@ietf.org; Fri, 17 Mar 2006 16:51:18 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMqr-0006f6-H0 for sip@ietf.org; Fri, 17 Mar 2006 16:51:18 -0500 Received: from rly01b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly01b.srv.mailcontrol.com (MailControl) with ESMTP id k2HLpGqP028589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Mar 2006 21:51:16 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly01b.srv.mailcontrol.com (MailControl) id k2HLowvY027954 for sip@ietf.org; Fri, 17 Mar 2006 21:50:58 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly01b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k2HLor7H027837; Fri, 17 Mar 2006 21:50:58 +0000 (GMT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] SBCs and draft-ietf-sip-identity-06 Date: Fri, 17 Mar 2006 21:50:53 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78C52@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SBCs and draft-ietf-sip-identity-06 Thread-Index: AcZKB/FJMBDlOLX7EdqAeQARJEEJ/AABNMjw From: "Chris Boulton" To: "Cullen Jennings" , "Dean Willis" , "Hans Persson" X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.66.1.111 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 > I didn't say it actually worked. That's part of the problem with B2BUAs. >=20 > -- You wouldn't have the UA check the identity. It delegated that job to the B2BUA when it asked the B2BUA to act on it's behalf.=20 [Chris Boulton] Just to clarify - why would you bother signing it if it was not going to be checked? Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 17 16:53:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMrW-0000wg-TH; Fri, 17 Mar 2006 16:51:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMrV-0000wW-DS for sip@ietf.org; Fri, 17 Mar 2006 16:51:57 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMrV-0006fj-3S for sip@ietf.org; Fri, 17 Mar 2006 16:51:57 -0500 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2HLqLMJ005230 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Mar 2006 15:52:22 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 Date: Fri, 17 Mar 2006 15:51:55 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "sip@ietf.org" , Hans Persson X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 17, 2006, at 3:15 PM, Cullen Jennings wrote: > On 3/16/06 1:02 PM, "Dean Willis" wrote: > >>> ons 2006-03-15 klockan 16:36 -0600 skrev Dean Willis: >>> >>>> I believe it's an assertion that the call came from >>>> fluffy@cisco.com >>>> signed not by cisco.com but by ingate.com. >>> >>> How do I make such an assertion within the framework of Identity? >>> As far >>> as I can tell, a UA compliant with identity-06 will reject such a >>> request since the domain of the From header does not match the >>> domain of >>> the certificate of the signer. Or am I misunderstanding what you >>> mean? >>> >> >> I didn't say it actually worked. That's part of the problem with >> B2BUAs. >> >> -- > > You wouldn't have the UA check the identity. It delegated that job > to the > B2BUA when it asked the B2BUA to act on it's behalf. > Of course, then you need to check to make sure that the thing claiming to be your B2BUA both: 1) claims to have validated the identity as it saw it 2) really is your B2BUA and is not YAMITMA (yet another man in the middle attacker). I think this can be done with the basic mechanics of identity, but we need some discussion of trust anchors that's outside of what I think is there. #1 might could be satisfied by a "contract" between B2BUA and UA -- the B2BUA has contracted to check any expressed identities and remove or flag ones it thinks are invalid. We need a way to assert, in the signaling, that this contract is being exercised. I think. #2 might could be satisfied by a TLS or equivalent SA to the B2BUA. Of course, this assumes an increasingly tenuous transitive SA as additional proxies appear between B2BUA and UA. And I don't like it. What if we extended the logic to be "Domain of the From: header must match the domain of the certificate of the signer" OR "the certificate of the signer MUST match the transitive trust domain of the recipient"? So if an identity saying "george.washington@founders.us.gov" appears in my inbox, signed by "cisco.com", and my UA is configured to believe transitive identifications made by "cisco.com", then my UA thinks it has received a call from President George Washington. I dunno, maybe I'm confused. -- 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 Mar 17 19:59:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKPlE-0007bF-0d; Fri, 17 Mar 2006 19:57:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKPlC-0007aH-ET for sip@ietf.org; Fri, 17 Mar 2006 19:57:38 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKPlC-0004La-6q for sip@ietf.org; Fri, 17 Mar 2006 19:57:38 -0500 Received: from [172.17.2.251] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2I0vblG011883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Mar 2006 18:57:37 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441B5AFF.2030909@nostrum.com> Date: Fri, 17 Mar 2006 18:57:35 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] The Problem with PRACK References: <475FF955A05DD411980D00508B6D5FB0124F94D5@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0124F94D5@en0033exch001u.uk.lucent.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Drage, Keith (Keith) wrote: >If PRACK is bad, and I have not yet seen any technical evidence provided against it except that potentially it is hard to implement right... > You miss the point. Calling PRACK "potentially hard to implement right" is like referring to WWII as "a trifling difference of opinions." In Vancouver, Rohan put up a slide to demonstrate this issue graphically, but its impact hasn't been shared on the list. To that end, I'll point out that implementing the offer/answer procedures with PRACK requires a state machine with at least 52 states and 329 transitions. That's a *lot* of code, and the chances of getting it all right are pretty close to zero. All of which makes me very skeptical of arguments that we can't change PRACK because it has been widely implemented: I offer that it's highly unlikely that it has been implemented correctly even once. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 17 19:59:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKPlk-0007pc-Vk; Fri, 17 Mar 2006 19:58:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKPlj-0007pX-K3 for sip@ietf.org; Fri, 17 Mar 2006 19:58:11 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKPlj-0004Oq-CV for sip@ietf.org; Fri, 17 Mar 2006 19:58:11 -0500 Received: from [172.17.2.251] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2I0w6OU011891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Mar 2006 18:58:09 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441B5B1C.5050103@nostrum.com> Date: Fri, 17 Mar 2006 18:58:04 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] The Problem with PRACK References: <440E5E52.20500@cisco.com> <953beacc0603081551k1e9af9dfi8d6a6e7437a8d1fc@mail.gmail.com> <953beacc0603151846i57f6d3fdm4970043b8e3b9991@mail.gmail.com> In-Reply-To: <953beacc0603151846i57f6d3fdm4970043b8e3b9991@mail.gmail.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Rohan Mahy wrote: > I went back over the 102 messages in this thread and did not hear any > comments on my concrete proposals: > > - require RSeq to start at 1 > - only acknowledge the most recent provisional. if the UAS wants to > send as new provisional that completely replaces a previous one it can > send immediately. if the UAS wants to send a new provisional but > wants acknowledgement of a previous one, it has to wait for the PRACK. > - send a provisional every 1 minute whether reliable or not. (instead > of every one minute for unreliable and every 2.5 minutes for reliable) > - deprecate *offers* in PRACK (answers are still OK) > > comments on *this*? Out of curiosity, did you go through the exercise of putting together an offer/answer state machine that takes this change into account? Is it much simpler? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 17 21:10:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKQra-0002WZ-Dk; Fri, 17 Mar 2006 21:08:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKQrZ-0002WU-A9 for sip@ietf.org; Fri, 17 Mar 2006 21:08:17 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKQrX-0006n9-Vg for sip@ietf.org; Fri, 17 Mar 2006 21:08:17 -0500 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 k2I288N06951; Fri, 17 Mar 2006 21:08:09 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? Date: Fri, 17 Mar 2006 20:08:07 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF07C4129F@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? Thread-Index: AcZJyvNS2D3i45mOQFawNYbxbxlE2gAZbIXw From: "Francois Audet" To: "Elwell, John" , "Christian Jansson" , "Samir Srivastava" , "Cullen Jennings" , "Christer Holmberg \(JO/LMF\)" , "Hisham Khartabil" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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, the evidence presented so far pointed to the opposite, i.e., that a new method was actually slightly less resource intensive than STUN. > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Friday, March 17, 2006 05:57 > To: Christian Jansson; Srivastava, Samir [SC100:8826:EXCH];=20 > Cullen Jennings; Christer Holmberg (JO/LMF); Hisham=20 > Khartabil; sip@ietf.org > Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN=20 > requestprocessingfaste r than a SIP PING request processing? >=20 >=20 > Christian, >=20 > I agree, and I would also eliminate option 2, because it=20 > seems clear from evidence presented to date that any SIP=20 > method that is conformant with normal SIP rules will have a=20 > significant impact on scalability. >=20 > John=20 >=20 > > -----Original Message----- > > From: Christian Jansson [mailto:christian.jansson@hotsip.com] > > Sent: 17 March 2006 09:49 > > To: Samir Srivastava; Cullen Jennings; Christer Holmberg=20 > > (JO/LMF); Hisham Khartabil; sip@ietf.org > > Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN=20 > > requestprocessingfaster than a SIP PING request processing? > >=20 > > > Samir wrote: > > >STUN with magic binary cookie is hack too.That looks to me=20 > going back=20 > > >to binary protocols and defeating the purpose of text based SIP=20 > > >protocol. > >=20 > > So in principal you rather have something that is human=20 > readable than=20 > > something that works better in reality? > >=20 > >=20 > > >Another point "Every application protocol > > >should take of its own mess using its own primitives" . > >=20 > > You mean we should for example also use SIP instead of DNS,=20 > DHCP, and=20 > > RTP? In general I think it is better to use a tool that is designed=20 > > for the problem. > >=20 > > >Within SIP too all headers doesn't > > >apply to all methods, we are doing this to achive the performance. > >=20 > > SIP parsing and performance are not optimized, that is a=20 > fact. SIP and=20 > > human readability on the other hand... but who cares. > >=20 > > >So PING is lesser evil than STUN. > >=20 > > If PING was SIP I would have no problem with it, but as it=20 > is defined=20 > > right now PING is not SIP even though the draft wants it to=20 > be. And I=20 > > do not think we should standardize things that are plain wrong > > just because > > it for the moment does not seem to introduce any enormous problems. > >=20 > > I think we have 3 real options: > > 1. Double CRLF > > 2. A new real SIP method > > 3. STUN > >=20 > > Bad ideas: > > 4. Using OPTIONS is a bad idea as it has another purpose, and > > adding new > > method would cost us nothing and it would be very clear=20 > what was going > > on. > > 5. Using PING as it is being discussed right now is not an option as > > long as it is not SIP as it claims to be. I do not want to=20 > > see any more > > discussions of non-SIP things that just looks like SIP anymore. > >=20 > > / Christian Jansson > >=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=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=20 > sip Use sipping@ietf.org for new developments on the=20 > 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 Mar 17 22:30:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKS6k-0003Vf-4X; Fri, 17 Mar 2006 22:28:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKS6i-0003Va-Tj for sip@ietf.org; Fri, 17 Mar 2006 22:28:00 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKS6h-0000a2-KE for sip@ietf.org; Fri, 17 Mar 2006 22:28:00 -0500 Received: from [192.168.0.102] (ppp-70-249-144-46.dsl.rcsntx.swbell.net [70.249.144.46]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2I3RvQB019758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Mar 2006 21:27:57 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441B7E37.2010903@nostrum.com> Date: Fri, 17 Mar 2006 21:27:51 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? References: <1ECE0EB50388174790F9694F77522CCF07C4129F@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF07C4129F@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.144.46 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org, "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 John Elwell wrote: >...it seems clear from evidence presented to date that any SIP >method that is conformant with normal SIP rules will have a >significant impact on scalability. > > Francois Audet replied: >Actually, the evidence presented so far pointed to the opposite, >i.e., that a new method was actually slightly less resource intensive >than STUN. > > You are either misinterpreting Hisham's experiment or John's comment. John is referring to a new method that "is conformant with normal SIP rules." Hisham's experiment was using a TCP connection established for SIP to send a pile of bits that, upon casual examination, looks a whole lot like a SIP message but which most emphatically IS NOT. Jonathan and others have posted concrete examples in which doing what Hisham did makes the network fail in new and spectacular ways. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 18 00:32:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKU1G-0000ka-TY; Sat, 18 Mar 2006 00:30:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKU1F-0000kR-3h for sip@ietf.org; Sat, 18 Mar 2006 00:30:29 -0500 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKU1D-0004Ik-Q2 for sip@ietf.org; Sat, 18 Mar 2006 00:30:29 -0500 Received: from [192.168.1.101] (pool-70-17-203-185.balt.east.verizon.net [70.17.203.185]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k2I5UK411249; Fri, 17 Mar 2006 23:30:20 -0600 Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? From: "Frank W. Miller" To: Adam Roach In-Reply-To: <441B7E37.2010903@nostrum.com> References: <1ECE0EB50388174790F9694F77522CCF07C4129F@zrc2hxm0.corp.nortel.com> <441B7E37.2010903@nostrum.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Sat, 18 Mar 2006 00:30:17 -0500 Message-Id: <1142659817.2712.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org, Francois Audet , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2006-03-17 at 21:27 -0600, Adam Roach wrote: > John Elwell wrote: > > >...it seems clear from evidence presented to date that any SIP > >method that is conformant with normal SIP rules will have a > >significant impact on scalability. > > > > > > Francois Audet replied: > > >Actually, the evidence presented so far pointed to the opposite, > >i.e., that a new method was actually slightly less resource intensive > >than STUN. > > > > > > You are either misinterpreting Hisham's experiment or John's comment. > > John is referring to a new method that "is conformant with normal SIP > rules." > > Hisham's experiment was using a TCP connection established for SIP to > send a pile of bits that, upon casual examination, looks a whole lot > like a SIP message but which most emphatically IS NOT. > > Jonathan and others have posted concrete examples in which doing what > Hisham did makes the network fail in new and spectacular ways. > IIRC, Jonathan's concerns centered on my proposal to not use the standard retransmissions associated with a NIT. The most recent version of the draft, -02, removes this based on the potential problems he identified. Sending a PING in this version initiates and maintains standard NITs along the signaling path. This makes the request very definitely a normal SIP message that follows all the normal rules. That said, the -02 version of the draft also includes a paragraph about the optimization discussed here for a UAS 200 OK response generation. The optimization is not required, but if the endpoint UAS uses it to turn a 200 around quickly, it can certainly make that transaction very quick. I know in my own UA implementation, I use a similar procedure for turning OPTIONS requests around and have never had any problems with it and its been tested against a number of other implementations. 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 Sat Mar 18 02:51:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKWCI-00086F-H5; Sat, 18 Mar 2006 02:50:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKWCG-00085y-3M for sip@ietf.org; Sat, 18 Mar 2006 02:50:00 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKWCB-0008KP-Nf for sip@ietf.org; Sat, 18 Mar 2006 02:49:57 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 5A18A13F982; Sat, 18 Mar 2006 09:49:54 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id D50BB13F910; Sat, 18 Mar 2006 09:49:43 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 0C64BF027F; Sat, 18 Mar 2006 09:50:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17435.48044.986415.760041@rautu.tutpro.com> Date: Sat, 18 Mar 2006 09:50:04 +0200 From: Juha Heinanen To: Rohan Mahy Subject: [Sip] Re: Comments to sip-outbound In-Reply-To: <39229.12.151.41.2.1142614255.squirrel@12.151.41.2> References: <441AD027.6030801@nokia.com> <39229.12.151.41.2.1142614255.squirrel@12.151.41.2> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org, Cullen Jennings , 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: , Errors-To: sip-bounces@ietf.org Rohan Mahy writes: > Jonathan actually suggested using > a separate (optional) type of SRV lookup to find your outbound proxy > set. i support that too. we MUST define how the SRV lookup is done before outbound is publishes and outbound RFC MUST mandate that every UA implementing outbound also implements the lookup. user MUST not need to configure manually anything else than AoR, username and password to the phone. -- 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 Sat Mar 18 02:56:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKWGj-00019F-J2; Sat, 18 Mar 2006 02:54:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKWGh-00019A-FU for sip@ietf.org; Sat, 18 Mar 2006 02:54:35 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKWGg-0000Bp-4Y for sip@ietf.org; Sat, 18 Mar 2006 02:54:35 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 7700A1403FA; Sat, 18 Mar 2006 09:54:33 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id DFD951403F4; Sat, 18 Mar 2006 09:54:27 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id ADD17F027F; Sat, 18 Mar 2006 09:54:58 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17435.48338.640125.585176@rautu.tutpro.com> Date: Sat, 18 Mar 2006 09:54:58 +0200 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] Comments to sip-outbound In-Reply-To: <1F5A6AB8-381D-48C0-BF20-3ABE6B3DA9BF@softarmor.com> References: <441AD027.6030801@nokia.com> <1F5A6AB8-381D-48C0-BF20-3ABE6B3DA9BF@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sip@ietf.org, Cullen Jennings , Aki Niemi , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 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, it is ok for the UA to allow manual configuration of anything (like registering to two proxys), but there MUST be a default mode of operation where nothing else is needed that AoR, username and passord. the rest it will learn via SRV queries. -- 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 Sat Mar 18 03:08:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKWSn-0001dl-Fl; Sat, 18 Mar 2006 03:07:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKWSm-0001dg-FE for sip@ietf.org; Sat, 18 Mar 2006 03:07:04 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKWSl-0000hH-4A for sip@ietf.org; Sat, 18 Mar 2006 03:07:04 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 4A82A1403FA; Sat, 18 Mar 2006 10:07:02 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id A8E241403F4; Sat, 18 Mar 2006 10:06:56 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id EE8CFF027F; Sat, 18 Mar 2006 10:07:23 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17435.49083.918877.151883@rautu.tutpro.com> Date: Sat, 18 Mar 2006 10:07:23 +0200 From: Juha Heinanen To: Adam Roach Subject: Re: [Sip] The Problem with PRACK In-Reply-To: <441B5AFF.2030909@nostrum.com> References: <475FF955A05DD411980D00508B6D5FB0124F94D5@en0033exch001u.uk.lucent.com> <441B5AFF.2030909@nostrum.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 Adam Roach writes: > All of which makes me very skeptical of arguments that we can't change > PRACK because it has been widely implemented: I offer that it's highly > unlikely that it has been implemented correctly even once. this has been my practical experience based on phones bought by users of my proxy. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 18 05:12:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKYNu-0001VG-Mz; Sat, 18 Mar 2006 05:10:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKYNt-0001VB-7X for sip@ietf.org; Sat, 18 Mar 2006 05:10:09 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKYNs-0003yW-Fs for sip@ietf.org; Sat, 18 Mar 2006 05:10:09 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EDA944F0001; Sat, 18 Mar 2006 11:10:06 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 11:10:06 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 11:10:06 +0100 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] The Problem with PRACK Date: Sat, 18 Mar 2006 11:10:05 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B69@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZJ9y2QgC2IFOn3TJWsbZdYmZRV7QAe24hg From: "Christer Holmberg \(JO/LMF\)" To: "Brett Tate" X-OriginalArrivalTime: 18 Mar 2006 10:10:06.0486 (UTC) FILETIME=[2178BB60:01C64A74] X-Brightmail-Tracker: AAAAAA== 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 Hi,=20 >>- only acknowledge the most recent provisional. >>if the UAS wants to send as new provisional that completely replaces=20 >>a previous one it can send immediately. if the UAS wants to send a=20 >>new provisional but wants acknowledgement of a previous one, it has=20 >>to wait for the PRACK. > =09 >>I assume RSeq would still be checked so UAC is able to notice out of=20 >>order provisional responses. >=20 >[CHH] What to you mean by "replace a provisional response"??? My interpretation is that the UAC no longer has to follow the rfc3262 requirement to drop 1xx responses which incremented by more than 1. And if the contents of the prior 1xx must not be ignored, the UAS must queue subsequent 1xx until prior one is acknowledged. The text basically shifts the MUST burden of ensuring no ignored 1xx's to UAS instead of the UAC. [CHH] I don't like the queueing. I think it should work as today, but the UAC should be aware of the first Rseq value, which means we can get rid of the queueing all together. The UAS sends a rel18x when it has one to send, and the UAC shall make sure it processes the rel18xs in the correct order, and discard responses which Rseq value is incremented by more than 1. In real life scenarios I am pretty sure the responses will come to the UAC in the correct order, becuase an UAS will probably re-send a rel18x response before the next rel18x is to be sent. >[CHH] and I DO think we should get rid of the rule by mandating=20 >an offer in the first rel18x (if the INV didn't carry an offer). (I assume "by" was not intentional within the above text.) [CHH] Yes :) >This is a common non compliance because of vendors deploying draft versions of the 100rel functionality. And vendors=20 >which supported 100rel and haven't implemented/upgraded to rfc3262 are currently required to deactivate 100rel to avoid=20 >non compliance to offer/answer usages. =20 > >I agree that the MUST should be reduce to a SHOULD. I think the text was added for clipping and 183 type reasons; and=20 >there are other reasons for it. >The functionality is useful; however it disables the UAS from reliably sending a 18x unless able/willing to adhere to the=20 >offer/answer requirements. [CHH] I don't even think there should be a SHOULD. If the INVITE does not contain an offer, the offer must come in a reliable response - BUT, that can be the first rel18x, the 10000th rel18x, or the 200 OK. Implementation may of course choose to send the offer in the first rel18x - if there is an offer to send at that time - but shall not be mandated to do so. Then, if there is some "service" which really requires the offer to be present in the first rel18x that shall be part of the service description - not the "core" specification. 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 Sat Mar 18 05:52:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKZ12-0007ym-7q; Sat, 18 Mar 2006 05:50:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKZ10-0007ye-TM for sip@ietf.org; Sat, 18 Mar 2006 05:50:34 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKZ0y-000582-Dq for sip@ietf.org; Sat, 18 Mar 2006 05:50:34 -0500 Received: (qmail 22315 invoked by uid 0); 18 Mar 2006 10:50:28 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Mar 2006 10:50:28 -0000 Message-ID: <002801c64a79$c42eaf90$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Aki Niemi" References: <441A6F0D.2080109@nokia.com> <441AAD3C.2070705@nokia.com> Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-02.txt Date: Sat, 18 Mar 2006 11:50:26 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.6 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: ext Cullen Jennings , 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 Aki, I agree with you that TCP per-connection keep-alive alone is not sufficient to cover all deployments. Also languages built on top of the OS (like Java, C# I don't know) don't currently offer it, presumably since it's not commonly available on all platforms. In my test I did not make any changes to the server side, so in my case it only depends on client side support. However, in real life there may be other prohibiting factors. Perhaps some NAT devices would block the keep-alive segments, I'm not sure I would propose that the outbound draft recommends "TCP per-connection keep-alive when available, else XXX", where XXX is still subject to vehement discussions. Condition is that the keep-alive interval can be set on individual connections to a random value between 95-120 seconds My point is that if TCP per-connection keep-alive is available, it should be the preferred choice as it is more scalable and efficient than the other alternatives being discussed (and more easy to implement / get right) Regards, Jeroen ----- Original Message ----- From: "Aki Niemi" To: "ext Aki Niemi" Cc: "ext Cullen Jennings" ; Sent: Friday, March 17, 2006 1:36 PM Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-02.txt > One more thing, Symbian only seems to support TCP keepalives with global > idle and probe intervals, and not per-connection basis. Meaning, > something else is still needed there. > > Cheers, > Aki > > ext Aki Niemi wrote: >> Hi, >> >> ext Cullen Jennings wrote: >>> On 3/14/06 11:55 AM, "Jeroen van Bemmel" wrote: >>> >>>> I have just done some basic testing on the Windows (XP) implementation >>>> of >>>> TCP keep-alive. >>>> >>>> I used the following code (s = a tcp socket): >>>> >>>> #include // for tcp_keepalive >>>> >>>> int val = TRUE; >>>> ::setsockopt( s, SOL_SOCKET, SO_DONTLINGER, (const char*) &val, >>>> sizeof(val) ); >>>> ::setsockopt( s, SOL_SOCKET, SO_KEEPALIVE, (const char*) &val, >>>> sizeof(val) ); >>>> ::setsockopt( s, IPPROTO_TCP, TCP_NODELAY, (const char*) &val, >>>> sizeof(val) ); >>>> >>>> tcp_keepalive settings; >>>> settings.onoff = 1; >>>> settings.keepaliveinterval = 1000; // interval of a probe when failed, >>>> in ms >>>> settings.keepalivetime = 60000; // every X ms, default is 2 hours >>>> DWORD nBytes=0; >>>> int r = ::WSAIoctl( s, SIO_KEEPALIVE_VALS, &settings, sizeof(settings), >>>> NULL, 0, &nBytes, NULL, NULL ); // succeeds, r==0 >>>> >>>> This causes the client to send a TCP keep-alive segment with SEG.SEQ = >>>> SND.NXT-1 as per RFC1122, containing 1 byte of garbage data (byte 00) >>>> and DF >>>> flag set. It sends the first probe 60 seconds after the connection has >>>> been >>>> idle (I only performed a TCP REGISTER over it), and repeats this every >>>> interval as specified. Different values give different intervals, and >>>> other >>>> connections are not affected. The server (a win2k machine I think) >>>> responds >>>> with a TCP ACK segment >>>> >>>> My conclusion: This seems usable... >>> agree >>> >>> Thank you. Any chance someone could try the equivalent things on some >>> other >>> OS? particularly Linux and Solaris? OSX? Other versions of windows? >> >> Is this strictly an OS issue? Can you set these options via the socket >> APIs of, say, Java or C#? >> >> I quickly tried on Linux, using perl's Socket module (wrapper for >> sys/socket.h and with PHP's socket functions. Both let you enable >> keepalives (SO_KEEPALIVE set to true), but both failed when I tried to >> set TCP-level options, namely TCP_KEEPIDLE and TCP_KEEPINTVL. It could >> be me, or then for those languages, only socket level options are >> supported. If this is so, and I didn't goof on some silly thing, with >> PHP or perl, you'd be left with the default idle time of 2 hours, before >> keepalives start (in 75 second intervals). >> >> Hope this helps. >> >> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 18 15:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKha6-0003gc-71; Sat, 18 Mar 2006 14:59:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKha3-0003ev-Nf; Sat, 18 Mar 2006 14:59:19 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKha2-0005Jt-Cq; Sat, 18 Mar 2006 14:59:19 -0500 Received: from [192.168.0.105] (pool-70-104-24-164.dllstx.fios.verizon.net [70.104.24.164]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2IJxEDw087463 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 18 Mar 2006 13:59:14 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> References: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Sat, 18 Mar 2006 13:59:16 -0600 To: Robert Sparks X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 70.104.24.164 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "sip@ietf.org WG" , sip-implementors@cs.columbia.edu, Sipping WG , "simple@ietf.org list" Subject: [Sip] SIPit 18 Registration closes in 2 weeks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Registration for SIPit 18 closes March 31 (13 days from now). If you are planning to attend, but have not already registered, please register now. Thanks, RjS On Feb 6, 2006, at 11:42 PM, Robert Sparks wrote: > Registration for SIPit 18 is open. > > This event will be held April 17-21 in > Akihabara, Tokyo, Japan. More information > about the event is available at http://www.sipit.net > and the host website at http://www.nic.ad.jp/en/sipit18/ > > Registration will close March 31. Please register early. > You can register now using https://www.regonline.com/88905 > > This 18th SIPForum SIPit is > > Hosted by: > - Japan Network Information Center (JPNIC) > > Co-hosted by: > - WIDE Project > - VoIP System Interoperability Task Force > > Supported by: > - Ministry of Internal Affairs and Communications (MIC) > - The Telecommunication Technology Committee (TTC) > - Telecom Service Association (TELESA) > - VoIP Forum Japan (VFJ) > - IPv6 Promotion Council (v6PC) > - ENUM Trial Japan (ETJP) > > Sponsors: > - Cisco Systems, Inc. > - Fractalist Inc. > - Fusion Communications Corporation > - Japan Telecom Co., Ltd. > - KDDI Corporation > - Mitsubishi Electric Information Network Corporation > - Mitsubishi Research Institute, Inc. > - NEC Corporation > - Netmarks Inc. > - Nippon Telegraph and Telephone Corporation > - Nippon Telegraph and Telephone East Corporation > - Nippon Telegraph and Telephone West Corporation > - NTT Advanced Technology Corporation > - Oki Electric Industry Co., Ltd. > - SoftBank BB Corp. > - Softfront > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 18 15:23:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKhvF-0006e7-DS; Sat, 18 Mar 2006 15:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKhvE-0006Ze-I4 for sip@ietf.org; Sat, 18 Mar 2006 15:21:12 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKhvD-000692-7S for sip@ietf.org; Sat, 18 Mar 2006 15:21:12 -0500 Received: from [192.168.0.111] (ppp-70-249-144-46.dsl.rcsntx.swbell.net [70.249.144.46]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2IKL41f088768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Mar 2006 14:21:10 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441C6BAA.2020106@nostrum.com> Date: Sat, 18 Mar 2006 14:20:58 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings , sip@ietf.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.144.46 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Sip] Outbound and 410 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 a slight bit concerned about the user experience that results from the interaction between sending of a 410 because of a loss of a flow and the way UAs interpret 410s. Imagine that I have a UA that doesn't know anything about the outbound extension. It knows about 410s, though: 410s mean that the AOR they're trying to use is forever gone. Cullen is using a UA that performs outbound to a proxy. So, I use my client to call Cullen. A flow ID is established at call setup time, and written into our route. Somewhere in the middle of the call, something goes wrong on Cullen's end, and his outbound connection to the proxy goes away. Now, I hang up. Because the flow indicated in my route is no longer any good, I get a 410 response to my BYE. Now, my client knows what 410 means: it means "The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent." Armed with this knowledge, it reacts to this error in a very reasonable way: it puts up a dialog box, "The address for Cullen Jennings is no longer valid, and no forwarding address is known. This condition is expected to be permanent. Should I permanently remove this address from your address book?" (Here I am thinking: "Oh. Of course. That's why the call was cut off: Cullen suddenly ceased to exist.") If we want to avoid inventing another code for this situation, I would argue that either 480 or 481 would likely result in more correct system behavior than 410. In fact, the interaction between using 481 for this purpose and RFC 3265 procedures appears to be more appropriate than the other choices in this case. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 18 16:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKj9i-0003LN-Ak; Sat, 18 Mar 2006 16:40:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKj9g-0003L4-VT for sip@ietf.org; Sat, 18 Mar 2006 16:40:12 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKj9f-0000Qy-Ln for sip@ietf.org; Sat, 18 Mar 2006 16:40:12 -0500 Received: from [192.168.0.111] (ppp-70-249-144-46.dsl.rcsntx.swbell.net [70.249.144.46]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2ILeAqS093111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Mar 2006 15:40:11 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441C7E31.4080801@nostrum.com> Date: Sat, 18 Mar 2006 15:40:01 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] New draft about etags in subscribe/notify References: <43D9DBFE.4060904@nokia.com> In-Reply-To: <43D9DBFE.4060904@nokia.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.144.46 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) 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 Aki: I like the overall approach you've chosen in this draft to solve the problem. I have a slight issue around re-use of the "SIP-If-None-Match" header field for the purpose you've defined here. The semantics of that header field (and other header fields with similar names, both in SIP and HTTP) is that of an absolute predicate: "I want this operation to succeed IF AND ONLY IF the following condition is true, and it MUST fail otherwise." That's not really what you mean here. What you really mean is something more like, "Suppress-Body-If-Match:" Aside from that issue, which I believe is largely aesthetic, the draft looks good to me on first reading. /a Aki Niemi wrote: > Hi All, > > I just submitted a new draft defining extensions to SIP events for > allowing conditional subscribes: > > http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-00.txt > > The issue this attempts to fix were documented in a sipping draft [1], > and discussed in IETF 63. My impression of that discussion was > moderate interest, so here's the mechanism proposal. > > Comments are very welcome. > > Cheers, > Aki > > [1] > http://www.softarmor.com/wgdb/docs/draft-niemi-sipping-subnot-issues-00.txt > (expired) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 18 18:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKkOA-0003wq-95; Sat, 18 Mar 2006 17:59:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKkO8-0003wj-H2 for sip@ietf.org; Sat, 18 Mar 2006 17:59:12 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKkO7-0002lV-5O for sip@ietf.org; Sat, 18 Mar 2006 17:59:12 -0500 Received: (qmail 31047 invoked by uid 0); 18 Mar 2006 22:59:08 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Mar 2006 22:59:08 -0000 Message-ID: <009801c64adf$8e647af0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Adam Roach" , "Cullen Jennings" , References: <441C6BAA.2020106@nostrum.com> Subject: Re: [Sip] Outbound and 410 Date: Sat, 18 Mar 2006 23:59:05 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) 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 Adam, > If we want to avoid inventing another code for this situation, I would > argue that either 480 or 481 would likely result in more correct system > behavior than 410. In fact, the interaction between using 481 for this > purpose and RFC 3265 procedures appears to be more appropriate than the > other choices in this case. The proxy should be able to distinguish between flow failure and temporary failures / non-existing calls, to implement the logic in section 6.2. I agree with you that 410 cannot be used here, but IMHO neither can 480/481. It looks like a new code is needed, something that says "Flow Gone" 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 Sun Mar 19 10:02:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzOD-0000ak-RE; Sun, 19 Mar 2006 10:00:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzOB-0000XV-S6 for sip@ietf.org; Sun, 19 Mar 2006 10:00:15 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKzO9-0005TW-D3 for sip@ietf.org; Sun, 19 Mar 2006 10:00:15 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JEwiJR008286; Sun, 19 Mar 2006 16:58:46 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 17:00:05 +0200 Received: from [10.162.252.50] ([10.162.252.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 19 Mar 2006 17:00:04 +0200 Message-ID: <441D7166.6030503@nokia.com> Date: Sun, 19 Mar 2006 16:57:42 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Rohan Mahy References: <441AD027.6030801@nokia.com> <39229.12.151.41.2.1142614255.squirrel@12.151.41.2> In-Reply-To: <39229.12.151.41.2.1142614255.squirrel@12.151.41.2> Content-Type: text/plain; charset=ISO-8859-1 X-OriginalArrivalTime: 19 Mar 2006 15:00:05.0109 (UTC) FILETIME=[CE45AA50:01C64B65] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext03.nokia.com id k2JEwiJR008286 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sip@ietf.org, Cullen Jennings Subject: [Sip] Re: Comments to sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 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, ext Rohan Mahy wrote: >> How about saying that the registrar domain returns the registrar URIs = in >> a 300 to REGISTER. Of course, in certain "rare" setups, the proxy set >> could also be returned in a 305. This would be optional, of course, an= d >> those domains that want to make things difficult could still rely on >> configuration. :) >=20 > The problem with using a 3xx is that we want the semantics to be that y= ou > register with all the provided outbound addresses. I agree the user > should need less to get started though. Jonathan actually suggested us= ing > a separate (optional) type of SRV lookup to find your outbound proxy se= t. SRV sounds like a good option. To make the redirection work, it might require a new 3xx that specifically says something like "Multiple Outbound Targets", and would be shown only to a UA that had, say, outbound in their supported. Not arguing this is any better necessarily than SRV, but it might enable more options for distributing load. For example, based on the first character of the userpart of the AoR. >> You don't really mean "forever" here, right? >=20 > Yeah, I don't like forever or infinite either. How about "indefinitely= "? Perhaps also an implementation note, that at some point, the process should abort with a user displayed error. >> In fact, it might be wise to separate the keepalive behavior of TCP an= d >> UDP a little better. In some sense, I agree with a previous post in th= at >> perhaps sip-outbound-tcp and sip-outbound-udp need not be that tied >> together in terms of keepalives and NAT binding detection. Remind me >> again why does the UA need to find out the NAT address/port with TCP? >=20 > First a disclaimer. I DONT CARE ANYMORE which keepalive technique we u= se > for TCP. >=20 > Using the OS-provided TCP keepalives is insufficient (too short). Are you saying NATs don't update their bindings on keepalives? Then that's really bad. There's one nice thing about TCP keepalives (where available) related to security. If you run TLS, TCP level keepalives would rid you of having to send data over the encrypted channel. > Using > double CRLF would work and STUN would both work. The argument in favor= of > STUN is that you would do the same thing over both transports so it wou= ld > be only one thing to implement. Then there's also this dummy UDP I've heard Juha Hein=E4nen talk about la= tely. 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 Sun Mar 19 10:20:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzfa-0005f8-OB; Sun, 19 Mar 2006 10:18:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzfZ-0005f3-Oz for sip@ietf.org; Sun, 19 Mar 2006 10:18:13 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKzfY-0006BP-Cg for sip@ietf.org; Sun, 19 Mar 2006 10:18:13 -0500 Received: (qmail 12115 invoked by uid 0); 19 Mar 2006 15:18:08 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 19 Mar 2006 15:18:08 -0000 Message-ID: <007301c64b68$52220100$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Aki Niemi" , "ext Rohan Mahy" References: <441AD027.6030801@nokia.com><39229.12.151.41.2.1142614255.squirrel@12.151.41.2> <441D7166.6030503@nokia.com> Subject: Re: [Sip] Re: Comments to sip-outbound Date: Sun, 19 Mar 2006 16:18:05 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, 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 > The problem with using a 3xx is that we want the semantics to be that you > register with all the provided outbound addresses. I agree the user > should need less to get started though. Jonathan actually suggested using > a separate (optional) type of SRV lookup to find your outbound proxy set. | SRV sounds like a good option. To make the redirection work, it might | require a new 3xx that specifically says something like "Multiple | Outbound Targets", and would be shown only to a UA that had, say, | outbound in their supported. Instead of a new 3xx code, perhaps a header similar to 'Request-Disposition' (RFC3841) would be more appropriate. Something like "Contact-Disposition: all" (absence of this header would retain current semantics) 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 Sun Mar 19 10:51:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0AG-0000pH-2T; Sun, 19 Mar 2006 10:49:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0AE-0000pC-EH for sip@ietf.org; Sun, 19 Mar 2006 10:49:54 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0AC-00078h-Rd for sip@ietf.org; Sun, 19 Mar 2006 10:49:54 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JFmT4m025659; Sun, 19 Mar 2006 17:48:29 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 17:49:48 +0200 Received: from [10.241.58.159] ([10.241.58.159]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 19 Mar 2006 17:49:47 +0200 Message-ID: <441D7D97.3090504@nokia.com> Date: Sun, 19 Mar 2006 17:49:43 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Francois Audet Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? References: <1ECE0EB50388174790F9694F77522CCF07C4129F@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF07C4129F@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 15:49:47.0786 (UTC) FILETIME=[C0160EA0:01C64B6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Cullen Jennings , sip@ietf.org, "Christer Holmberg \(JO/LMF\)" , "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 I agree. Pekka Pessi explained the issue already much better than I ever could: http://www1.ietf.org/mail-archive/web/sip/current/msg12841.html In summary: processing STUN and, say, OPTIONS consumes roughly the same amount of packets on-the-wire, system calls and both parsers (alone) fit in modern processor caches. So the bottleneck is somewhere else than in CPU, like in memory bus or network I/O. (This might actually be worse for a combined SIP+STUN parser, but I don't have concrete data on that unfortunately.) To which Jonathan replied that bandwidth is also an issue to consider, and would favor a protocol that was smaller on the wire: http://www1.ietf.org/mail-archive/web/sip/current/msg12842.html However, the data Jonathan presented assumes a proxy that only sees VoIP traffic. I don't think you can restrict "useful traffic" to VoIP only. If you take a proxy that not only sees INVITE/200/ACK, but presence and IM as well, the numbers change. I recently saw numbers from a real deployment that accounted almost 90% of the messages seen by proxies to be presence related; VoIP only accounted for approximately 6% of messages. The graphs didn't show bandwidth figures, but I'd expect them to be ever worse. Cheers, Aki ext Francois Audet wrote: > Actually, the evidence presented so far pointed to the opposite, > i.e., that a new method was actually slightly less resource intensive > than STUN. > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Friday, March 17, 2006 05:57 >> To: Christian Jansson; Srivastava, Samir [SC100:8826:EXCH]; >> Cullen Jennings; Christer Holmberg (JO/LMF); Hisham >> Khartabil; sip@ietf.org >> Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN >> requestprocessingfaste r than a SIP PING request processing? >> >> >> Christian, >> >> I agree, and I would also eliminate option 2, because it >> seems clear from evidence presented to date that any SIP >> method that is conformant with normal SIP rules will have a >> significant impact on scalability. >> >> John >> >>> -----Original Message----- >>> From: Christian Jansson [mailto:christian.jansson@hotsip.com] >>> Sent: 17 March 2006 09:49 >>> To: Samir Srivastava; Cullen Jennings; Christer Holmberg >>> (JO/LMF); Hisham Khartabil; sip@ietf.org >>> Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN >>> requestprocessingfaster than a SIP PING request processing? >>> >>>> Samir wrote: >>>> STUN with magic binary cookie is hack too.That looks to me >> going back >>>> to binary protocols and defeating the purpose of text based SIP >>>> protocol. >>> So in principal you rather have something that is human >> readable than >>> something that works better in reality? >>> >>> >>>> Another point "Every application protocol >>>> should take of its own mess using its own primitives" . >>> You mean we should for example also use SIP instead of DNS, >> DHCP, and >>> RTP? In general I think it is better to use a tool that is designed >>> for the problem. >>> >>>> Within SIP too all headers doesn't >>>> apply to all methods, we are doing this to achive the performance. >>> SIP parsing and performance are not optimized, that is a >> fact. SIP and >>> human readability on the other hand... but who cares. >>> >>>> So PING is lesser evil than STUN. >>> If PING was SIP I would have no problem with it, but as it >> is defined >>> right now PING is not SIP even though the draft wants it to >> be. And I >>> do not think we should standardize things that are plain wrong >>> just because >>> it for the moment does not seem to introduce any enormous problems. >>> >>> I think we have 3 real options: >>> 1. Double CRLF >>> 2. A new real SIP method >>> 3. STUN >>> >>> Bad ideas: >>> 4. Using OPTIONS is a bad idea as it has another purpose, and >>> adding new >>> method would cost us nothing and it would be very clear >> what was going >>> on. >>> 5. Using PING as it is being discussed right now is not an option as >>> long as it is not SIP as it claims to be. I do not want to >>> see any more >>> discussions of non-SIP things that just looks like SIP anymore. >>> >>> / Christian Jansson >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on >> current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current >> sip Use sipping@ietf.org for new developments on the >> application of sip >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 19 10:52:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0BC-00027g-W0; Sun, 19 Mar 2006 10:50:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0BB-00020r-Qc for sip@ietf.org; Sun, 19 Mar 2006 10:50:53 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0BA-00079T-D4 for sip@ietf.org; Sun, 19 Mar 2006 10:50:53 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JFokft003797; Sun, 19 Mar 2006 17:50:50 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 17:50:49 +0200 Received: from [10.241.58.159] ([10.241.58.159]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 19 Mar 2006 17:50:49 +0200 Message-ID: <441D7DD7.70008@nokia.com> Date: Sun, 19 Mar 2006 17:50:47 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Jeroen van Bemmel Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-02.txt References: <441A6F0D.2080109@nokia.com> <441AAD3C.2070705@nokia.com> <002801c64a79$c42eaf90$31713b51@BEMBUSTER> In-Reply-To: <002801c64a79$c42eaf90$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 15:50:49.0199 (UTC) FILETIME=[E4B0EFF0:01C64B6C] X-Spam-Score: 0.6 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ext Cullen Jennings , 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 ext Jeroen van Bemmel wrote: > I would propose that the outbound draft recommends "TCP per-connection > keep-alive when available, else XXX", where XXX is still subject to > vehement discussions. Condition is that the keep-alive interval can be > set on individual connections to a random value between 95-120 seconds I agree. > My point is that if TCP per-connection keep-alive is available, it > should be the preferred choice as it is more scalable and efficient than > the other alternatives being discussed (and more easy to implement / get > right) Yes, plus there is one interesting security property as well, since keepalives over an encrypted channel are potentially an easier target for someone sniffing the traffic in order to brake the session key. 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 Sun Mar 19 10:53:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0Bg-0002N4-Vb; Sun, 19 Mar 2006 10:51:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0Be-0002Mz-UB for sip@ietf.org; Sun, 19 Mar 2006 10:51:22 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0Bd-0007Aj-JU for sip@ietf.org; Sun, 19 Mar 2006 10:51:22 -0500 Received: from [131.161.248.91] (open-131-161-248-91.cliq.com [131.161.248.91]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k2JFpJF19142; Sun, 19 Mar 2006 07:51:19 -0800 In-Reply-To: <441D7166.6030503@nokia.com> References: <441AD027.6030801@nokia.com> <39229.12.151.41.2.1142614255.squirrel@12.151.41.2> <441D7166.6030503@nokia.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <24c93c1352cd57bde4924ff3309802f6@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sun, 19 Mar 2006 07:50:41 -0800 To: Aki Niemi X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings Subject: [Sip] Re: Comments to sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 19, 2006, at 6:57, Aki Niemi wrote: >>> In fact, it might be wise to separate the keepalive behavior of TCP >>> and >>> UDP a little better. In some sense, I agree with a previous post in >>> that >>> perhaps sip-outbound-tcp and sip-outbound-udp need not be that tied >>> together in terms of keepalives and NAT binding detection. Remind me >>> again why does the UA need to find out the NAT address/port with TCP? >> >> First a disclaimer. I DONT CARE ANYMORE which keepalive technique we >> use >> for TCP. >> >> Using the OS-provided TCP keepalives is insufficient (too short). > > Are you saying NATs don't update their bindings on keepalives? Then > that's really bad. No, that generally works. The problem is that the application won't detect a TCP keepalive failure for an annoyingly long period of time. I think there is an informational note on this in the draft, but I would not be surprised if it gets missed. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 19 10:56:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0F4-0004UG-Mg; Sun, 19 Mar 2006 10:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0F3-0004UB-7h for sip@ietf.org; Sun, 19 Mar 2006 10:54:53 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0F1-0007IZ-Q8 for sip@ietf.org; Sun, 19 Mar 2006 10:54:53 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JFqa2J026693; Sun, 19 Mar 2006 17:52:36 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 17:54:44 +0200 Received: from [10.241.58.159] ([10.241.58.159]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 19 Mar 2006 17:54:43 +0200 Message-ID: <441D7EC0.8050607@nokia.com> Date: Sun, 19 Mar 2006 17:54:40 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Rohan Mahy References: <441AD027.6030801@nokia.com> <39229.12.151.41.2.1142614255.squirrel@12.151.41.2> <441D7166.6030503@nokia.com> <24c93c1352cd57bde4924ff3309802f6@ekabal.com> In-Reply-To: <24c93c1352cd57bde4924ff3309802f6@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 15:54:43.0718 (UTC) FILETIME=[7079B260:01C64B6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, Cullen Jennings Subject: [Sip] Re: Comments to sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Rohan Mahy wrote: >> Are you saying NATs don't update their bindings on keepalives? Then >> that's really bad. > > No, that generally works. The problem is that the application won't > detect a TCP keepalive failure for an annoyingly long period of time. I > think there is an informational note on this in the draft, but I would > not be surprised if it gets missed. This has been the topic of a parallel thread. Some (most?) OSs actually let you configure the idle times, probe intervals and the number of probes on a per-connection basis. It's not available universally (depends on the OS and the programming language) but where available, is the best choice. Things have changed since the note on the draft. ;) 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 Sun Mar 19 11:46:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL11W-0002yG-4l; Sun, 19 Mar 2006 11:44:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL11U-0002yA-9M for sip@ietf.org; Sun, 19 Mar 2006 11:44:56 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL11U-0000Qi-1j for sip@ietf.org; Sun, 19 Mar 2006 11:44:56 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2JGidj5005784; Sun, 19 Mar 2006 10:44:39 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 19 Mar 2006 16:44:38 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0127488E2@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Christian Jansson , Paul Kyzivat , Juha Heinanen Subject: RE: [Sip] The Problem with PRACK Date: Sun, 19 Mar 2006 16:44:27 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip@ietf.org, Dean Willis , Brett Tate , "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 You misconstrue. My argument was that in the absence of a charging model, IETF has to assume that other organisations, or even the operator's themselves develop their own, and IETF has to cater for that. Moreover the argument Juha was developing was that we have have a technical solution that would appear to preclude charging for allocated resource at the user access on a per session basis. While that may not be everyone's cup of tea, I certainly do not see anything more walled garden about that than charging for bytes transferred across the access, or charging for total bandwidth of the access pipe. regards Keith > -----Original Message----- > From: Christian Jansson [mailto:christian.jansson@hotsip.com] > Sent: 16 March 2006 20:25 > To: Drage, Keith (Keith); Paul Kyzivat; Juha Heinanen > Cc: sip@ietf.org; Christer Holmberg (JO/LMF); Dean Willis; Brett Tate > Subject: RE: [Sip] The Problem with PRACK > > > > > >From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > >As IETF has not specified a charging model for SIP, or the resources > under > >the control of SIP, and does not intend to, I would suggest that we > have to > >assume there is no such restriction, and therefore have to make sure > our > >protocol supports a multitude of charging cases. > > > Is your opinion that HTTP is big failure just because they did not > specify a charging model? Is your opinion that it is impossible to get > paid for services on the internet? > > I think the problem is the vision you have of the walled-in > environment, > with the "multitude of charging cases", with "all" the specially > selected applications that a customer would ever want in the > control of > the IMS operator. In this environment the user should completely trust > his IMS operator, no end-to-end crypto stuff allowed, because > as it was > said in an earlier mail today, the cscf would probably need to do some > "deep inspection" before letting the request go out to the open > Internet. In contrast to the trust the user has to have for the > operator, the operator does not even trust the user to handle > basic sip > headers, that is, the topology has to be hidden. Who knows what would > happen otherwise, perhaps the user would want to skip/replace some of > the nice services that the operator so kindly have provided him with. > (To me it seems that the services are more of a service to > the operator > than to the user?) > > Of course I think that it should be possible to get paid for > delivering > VoIP services, but perhaps not exactly the same way as it was designed > over 100 years ago, because in that case we could have stayed > with PSTN > and the GSM systems that we have. > > / Christian Jansson > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 19 11:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL17r-0007ej-M9; Sun, 19 Mar 2006 11:51:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL17p-0007ee-RF for sip@ietf.org; Sun, 19 Mar 2006 11:51:29 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL17p-0000gB-ES for sip@ietf.org; Sun, 19 Mar 2006 11:51:29 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JGnKgd022818; Sun, 19 Mar 2006 18:49:20 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 18:51:28 +0200 Received: from [10.241.58.228] ([10.241.58.228]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 19 Mar 2006 18:51:27 +0200 Message-ID: <441D8BC2.90401@nokia.com> Date: Sun, 19 Mar 2006 18:50:10 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Adam Roach Subject: Re: [Sip] New draft about etags in subscribe/notify References: <43D9DBFE.4060904@nokia.com> <441C7E31.4080801@nostrum.com> In-Reply-To: <441C7E31.4080801@nostrum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 16:51:27.0307 (UTC) FILETIME=[5D2C29B0:01C64B75] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Adam, ext Adam Roach wrote: > That's not really what you mean here. What you really mean is something > more like, "Suppress-Body-If-Match:" I agree. There is one issue that is related to this, namely whether suppressing the notify body is sufficient, or would there be need to do something more radical, like true If-No-Match and 412. I'll post this, and a proposal separately. 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 Sun Mar 19 11:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL17u-0007lZ-FI; Sun, 19 Mar 2006 11:51:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL17t-0007gJ-4w for sip@ietf.org; Sun, 19 Mar 2006 11:51:33 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL17s-0000gJ-Nn for sip@ietf.org; Sun, 19 Mar 2006 11:51:33 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JGnMC1022841 for ; Sun, 19 Mar 2006 18:49:24 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 18:51:29 +0200 Received: from [10.241.58.228] ([10.241.58.228]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 19 Mar 2006 18:51:29 +0200 Message-ID: <441D8BC7.8000402@nokia.com> Date: Sun, 19 Mar 2006 18:50:15 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 16:51:29.0683 (UTC) FILETIME=[5E96B630:01C64B75] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Sip] Open issue in subnot-etags: suppress body or entire NOFITY? X-BeenThere: sip@ietf.org X-Mailman-Version: 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 cases where etags should work are basically these: 1) Subscription refresh. The expiry needs to be updated, so the conditional SUBSCRIBE will need to succeed 2xx. Potentially, the entire NOTIFY could be suppressed, since the Subscription-State ought to be known at that point already. 2) Subscription resume. A new subscription that continues from a past, terminated subscription. There, we can't suppress the entire first NOTIFY, since it is needed to complete the dialog. Suppressing the body works fine. 3) Fetch This SUBSCRIBE will ever only trigger one NOTIFY at most, so suppressing that in case the state is know would work. Out of these, #1 at least requires a 200-class response to the SUBSCRIBE; #2 requires at least a 200-class response and the first NOTIFY without a body; #3 could do with the HTTP-style If-None-Match in SUBSCRIBE and a 412 response. Proposal 1) Same machanism for all. Clearly, the lowest common denominator is, as Adam suggests, a Suppress-Body-If-Match header field in a SUBSCRIBE. If this condition succeeds, the NOTIFY is sent but with an empty body. Proposal is to use this mechanism for all cases above. Proposal 2) Differentiate subscriptions and fetches. All subscriptions would use Suppress-Body-If-Match like above, and fetches/polls would use another Notify-If-No-Match header field, and when that condition fails, the SUBSCRIBE gets a 412 response, and no NOTIFY is sent. Proposal 3) Differentiate all of the three cases. Subscription refreshes would use Suppress-Notify-If-Match, as above; subscription resumes would use Suppress-Body-If-Match, as above; fetches and polls would use Notify-If-No-Match as above. I'd personally go with proposal 1, simply to keep this sweet and simple. But I don't think proposal 2 or 3 sound entirely unreasonable either. COmments? 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 Sun Mar 19 11:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL17r-0007ej-M9; Sun, 19 Mar 2006 11:51:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL17p-0007ee-RF for sip@ietf.org; Sun, 19 Mar 2006 11:51:29 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL17p-0000gB-ES for sip@ietf.org; Sun, 19 Mar 2006 11:51:29 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JGnKgd022818; Sun, 19 Mar 2006 18:49:20 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 18:51:28 +0200 Received: from [10.241.58.228] ([10.241.58.228]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 19 Mar 2006 18:51:27 +0200 Message-ID: <441D8BC2.90401@nokia.com> Date: Sun, 19 Mar 2006 18:50:10 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Adam Roach Subject: Re: [Sip] New draft about etags in subscribe/notify References: <43D9DBFE.4060904@nokia.com> <441C7E31.4080801@nostrum.com> In-Reply-To: <441C7E31.4080801@nostrum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 16:51:27.0307 (UTC) FILETIME=[5D2C29B0:01C64B75] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Adam, ext Adam Roach wrote: > That's not really what you mean here. What you really mean is something > more like, "Suppress-Body-If-Match:" I agree. There is one issue that is related to this, namely whether suppressing the notify body is sufficient, or would there be need to do something more radical, like true If-No-Match and 412. I'll post this, and a proposal separately. 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 Sun Mar 19 11:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL17u-0007lZ-FI; Sun, 19 Mar 2006 11:51:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL17t-0007gJ-4w for sip@ietf.org; Sun, 19 Mar 2006 11:51:33 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL17s-0000gJ-Nn for sip@ietf.org; Sun, 19 Mar 2006 11:51:33 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JGnMC1022841 for ; Sun, 19 Mar 2006 18:49:24 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 18:51:29 +0200 Received: from [10.241.58.228] ([10.241.58.228]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 19 Mar 2006 18:51:29 +0200 Message-ID: <441D8BC7.8000402@nokia.com> Date: Sun, 19 Mar 2006 18:50:15 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 16:51:29.0683 (UTC) FILETIME=[5E96B630:01C64B75] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Sip] Open issue in subnot-etags: suppress body or entire NOFITY? X-BeenThere: sip@ietf.org X-Mailman-Version: 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 cases where etags should work are basically these: 1) Subscription refresh. The expiry needs to be updated, so the conditional SUBSCRIBE will need to succeed 2xx. Potentially, the entire NOTIFY could be suppressed, since the Subscription-State ought to be known at that point already. 2) Subscription resume. A new subscription that continues from a past, terminated subscription. There, we can't suppress the entire first NOTIFY, since it is needed to complete the dialog. Suppressing the body works fine. 3) Fetch This SUBSCRIBE will ever only trigger one NOTIFY at most, so suppressing that in case the state is know would work. Out of these, #1 at least requires a 200-class response to the SUBSCRIBE; #2 requires at least a 200-class response and the first NOTIFY without a body; #3 could do with the HTTP-style If-None-Match in SUBSCRIBE and a 412 response. Proposal 1) Same machanism for all. Clearly, the lowest common denominator is, as Adam suggests, a Suppress-Body-If-Match header field in a SUBSCRIBE. If this condition succeeds, the NOTIFY is sent but with an empty body. Proposal is to use this mechanism for all cases above. Proposal 2) Differentiate subscriptions and fetches. All subscriptions would use Suppress-Body-If-Match like above, and fetches/polls would use another Notify-If-No-Match header field, and when that condition fails, the SUBSCRIBE gets a 412 response, and no NOTIFY is sent. Proposal 3) Differentiate all of the three cases. Subscription refreshes would use Suppress-Notify-If-Match, as above; subscription resumes would use Suppress-Body-If-Match, as above; fetches and polls would use Notify-If-No-Match as above. I'd personally go with proposal 1, simply to keep this sweet and simple. But I don't think proposal 2 or 3 sound entirely unreasonable either. COmments? 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 Sun Mar 19 13:15:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL2Ot-0002Rb-89; Sun, 19 Mar 2006 13:13:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL2Or-0002RJ-3X for sip@ietf.org; Sun, 19 Mar 2006 13:13:09 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL2Op-0003nZ-Ns for sip@ietf.org; Sun, 19 Mar 2006 13:13:09 -0500 Received: (qmail 20148 invoked by uid 0); 19 Mar 2006 18:13:01 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 19 Mar 2006 18:13:01 -0000 Message-ID: <009001c64b80$bfb40160$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" , "Aki Niemi" References: <441AD027.6030801@nokia.com><39229.12.151.41.2.1142614255.squirrel@12.151.41.2><441D7166.6030503@nokia.com> <24c93c1352cd57bde4924ff3309802f6@ekabal.com> Subject: Re: [Sip] Re: Comments to sip-outbound Date: Sun, 19 Mar 2006 19:12:56 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, Rohan Mahy , 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 Rohan, >> Are you saying NATs don't update their bindings on keepalives? Then >> that's really bad. > > No, that generally works. The problem is that the application won't > detect a TCP keepalive failure for an annoyingly long period of time. I > think there is an informational note on this in the draft, but I would not > be surprised if it gets missed. > I just did another small test: setting TCP keep-alive interval to a random value between 95 and 120 seconds, with repeat interval at 1 second. When I disconnect the server cable, a TCP-keepalive is sent when the interval timer expires, and retransmitted 4 times with 1-second intervals (so in total 5 tries). This means that with these settings, failure is detected after 125 seconds (worst case). The application gets an IO event with NT_STATUS_REMOTE_DISCONNECT (0xc000013c) I suppose the recommended value for the repeat interval would be T1. I am not sure if the number of retries can be set per connection, probably not. 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 Sun Mar 19 14:05:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL3C1-0004qk-5H; Sun, 19 Mar 2006 14:03:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL3C0-0004qf-7B for sip@ietf.org; Sun, 19 Mar 2006 14:03:56 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL3By-0005Ul-PR for sip@ietf.org; Sun, 19 Mar 2006 14:03:56 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JJ2RgV026332; Sun, 19 Mar 2006 21:02:27 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 21:03:46 +0200 Received: from [10.241.58.24] ([10.241.58.24]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 19 Mar 2006 21:03:46 +0200 Message-ID: <441DAB0F.9060105@nokia.com> Date: Sun, 19 Mar 2006 21:03:43 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Jeroen van Bemmel Subject: Re: [Sip] Re: Comments to sip-outbound References: <441AD027.6030801@nokia.com><39229.12.151.41.2.1142614255.squirrel@12.151.41.2><441D7166.6030503@nokia.com> <24c93c1352cd57bde4924ff3309802f6@ekabal.com> <009001c64b80$bfb40160$31713b51@BEMBUSTER> In-Reply-To: <009001c64b80$bfb40160$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 19:03:46.0671 (UTC) FILETIME=[D966F7F0:01C64B87] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org, Rohan Mahy , 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 ext Jeroen van Bemmel wrote: > I suppose the recommended value for the repeat interval would be T1. I > am not sure if the number of retries can be set per connection, probably > not. At least in Linux, you can set this via TCP_KEEPCNT, and at least in my running kernel (2.6.12), it's implemented as well. But another thing occurred to me about the use of TCP keepalives. Since they are only hop-by-hop, they may not guarantee a flow is alive in the presence of proxy or proxies in the path to a registrar. At least not in the same way a CRLFx2 would. 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 Sun Mar 19 15:56:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4vU-0000Bd-DW; Sun, 19 Mar 2006 15:55:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4vT-00007M-Eu for sip@ietf.org; Sun, 19 Mar 2006 15:54:59 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL4vT-0001i1-0R for sip@ietf.org; Sun, 19 Mar 2006 15:54:59 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWE006017AYWA@siemenscomms.co.uk> for sip@ietf.org; Sun, 19 Mar 2006 20:52:11 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWE006157AYJM@siemenscomms.co.uk>; Sun, 19 Mar 2006 20:52:10 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sun, 19 Mar 2006 20:54:57 +0000 Content-return: allowed Date: Sun, 19 Mar 2006 20:54:16 +0000 From: "Elwell, John" Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN requestprocessingfaste r than a SIP PING request processing? To: Francois Audet , Christian Jansson , Samir Srivastava , Cullen Jennings , "Christer Holmberg (JO/LMF)" , Hisham Khartabil , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667086B0661@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 Francois, It has been difficult to keep track of this very long thread, but I seem to recall that the evidence suggested a new SIP method would only be quicker than STUN if it took certain short-cuts and did not involve the normal processing that would apply to any other SIP request. Then it would not really be SIP but some other protocol. I agree then it might be marginally quicker than STUN. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 18 March 2006 02:08 > To: Elwell, John; Christian Jansson; Samir Srivastava; Cullen > Jennings; Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org > Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN > requestprocessingfaste r than a SIP PING request processing? > > Actually, the evidence presented so far pointed to the opposite, > i.e., that a new method was actually slightly less resource intensive > than STUN. > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Friday, March 17, 2006 05:57 > > To: Christian Jansson; Srivastava, Samir [SC100:8826:EXCH]; > > Cullen Jennings; Christer Holmberg (JO/LMF); Hisham > > Khartabil; sip@ietf.org > > Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN > > requestprocessingfaste r than a SIP PING request processing? > > > > > > Christian, > > > > I agree, and I would also eliminate option 2, because it > > seems clear from evidence presented to date that any SIP > > method that is conformant with normal SIP rules will have a > > significant impact on scalability. > > > > John > > > > > -----Original Message----- > > > From: Christian Jansson [mailto:christian.jansson@hotsip.com] > > > Sent: 17 March 2006 09:49 > > > To: Samir Srivastava; Cullen Jennings; Christer Holmberg > > > (JO/LMF); Hisham Khartabil; sip@ietf.org > > > Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN > > > requestprocessingfaster than a SIP PING request processing? > > > > > > > Samir wrote: > > > >STUN with magic binary cookie is hack too.That looks to me > > going back > > > >to binary protocols and defeating the purpose of text based SIP > > > >protocol. > > > > > > So in principal you rather have something that is human > > readable than > > > something that works better in reality? > > > > > > > > > >Another point "Every application protocol > > > >should take of its own mess using its own primitives" . > > > > > > You mean we should for example also use SIP instead of DNS, > > DHCP, and > > > RTP? In general I think it is better to use a tool that > is designed > > > for the problem. > > > > > > >Within SIP too all headers doesn't > > > >apply to all methods, we are doing this to achive the > performance. > > > > > > SIP parsing and performance are not optimized, that is a > > fact. SIP and > > > human readability on the other hand... but who cares. > > > > > > >So PING is lesser evil than STUN. > > > > > > If PING was SIP I would have no problem with it, but as it > > is defined > > > right now PING is not SIP even though the draft wants it to > > be. And I > > > do not think we should standardize things that are plain wrong > > > just because > > > it for the moment does not seem to introduce any enormous > problems. > > > > > > I think we have 3 real options: > > > 1. Double CRLF > > > 2. A new real SIP method > > > 3. STUN > > > > > > Bad ideas: > > > 4. Using OPTIONS is a bad idea as it has another purpose, and > > > adding new > > > method would cost us nothing and it would be very clear > > what was going > > > on. > > > 5. Using PING as it is being discussed right now is not > an option as > > > long as it is not SIP as it claims to be. I do not want to > > > see any more > > > discussions of non-SIP things that just looks like SIP anymore. > > > > > > / Christian Jansson > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sipping@ietf.org for new developments on the > > application of sip > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 19 16:45:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL5gc-00058Y-KU; Sun, 19 Mar 2006 16:43:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL5gb-00053g-HM for sip@ietf.org; Sun, 19 Mar 2006 16:43:41 -0500 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL5gb-0003Vc-42 for sip@ietf.org; Sun, 19 Mar 2006 16:43:41 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2JLhXG10573; Sun, 19 Mar 2006 16:43:33 -0500 (EST) 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] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sun, 19 Mar 2006 15:43:25 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AF53B69@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? Thread-Index: AcZLbMp1gDRA+araQCWT8/CIAPw8awAJlBoA From: "Samir Srivastava" To: "Aki Niemi" , "Francois Audet" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Cullen Jennings , sip@ietf.org, "Christer Holmberg \(JO/LMF\)" , "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 Major portion of Overload and Congestion handling should be done in *out-of-band* manner. Handling most of that on the same signaling ( already overloaded/congested ) channel is architecturally incorrect, though there can be some SIP signaling messages for it. That's where SIP MIB comes into the picture. Overload / Congestion compliance will make more vendors to implement SIP MIB, which is of low traction currently.=20 SIP MIB captures the stats per method basis. It will be easy to extend it for PING and find out the PING load (Which is a lot, refer Jonathan' email link) in out-of-band manner. Finding STUN keep alive load using MIB-II objects is not possible. MIB-II objects doesn't have per port stats. There counters are transport protocol based. So it will not be possible to catch CRLF stats from there. Choices are :- 1) Extend MIB II to have per port basis stats. Which is not a available route as SIP needs granular stats it better should have in its own MIB. 2) Treat STUN CRLF keep alive as SIP method for stats capturing (Bad design). 3) Have PING method (which purist doesn't like). IMHO 3) is best among the *available* choices for overload and congestion problem to be addressed in future. Thx Samir =20 -----Original Message----- From: Aki Niemi [mailto:aki.niemi@nokia.com]=20 Sent: Sunday, March 19, 2006 7:50 AM To: Audet, Francois [SC100:3055:EXCH] Cc: Elwell, John; Christian Jansson; Srivastava, Samir [SC100:8826:EXCH]; Cullen Jennings; Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? I agree. Pekka Pessi explained the issue already much better than I ever could: http://www1.ietf.org/mail-archive/web/sip/current/msg12841.html In summary: processing STUN and, say, OPTIONS consumes roughly the same amount of packets on-the-wire, system calls and both parsers (alone) fit in modern processor caches. So the bottleneck is somewhere else than in CPU, like in memory bus or network I/O. (This might actually be worse for a combined SIP+STUN parser, but I don't have concrete data on that unfortunately.) To which Jonathan replied that bandwidth is also an issue to consider, and would favor a protocol that was smaller on the wire: http://www1.ietf.org/mail-archive/web/sip/current/msg12842.html However, the data Jonathan presented assumes a proxy that only sees VoIP traffic. I don't think you can restrict "useful traffic" to VoIP only. If you take a proxy that not only sees INVITE/200/ACK, but presence and IM as well, the numbers change. I recently saw numbers from a real deployment that accounted almost 90% of the messages seen by proxies to be presence related; VoIP only accounted for approximately 6% of messages. The graphs didn't show bandwidth figures, but I'd expect them to be ever worse. Cheers, Aki ext Francois Audet wrote: > Actually, the evidence presented so far pointed to the opposite, i.e., > that a new method was actually slightly less resource intensive than=20 > STUN. >=20 >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Friday, March 17, 2006 05:57 >> To: Christian Jansson; Srivastava, Samir [SC100:8826:EXCH]; Cullen=20 >> Jennings; Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org >> Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN=20 >> requestprocessingfaste r than a SIP PING request processing? >> >> >> Christian, >> >> I agree, and I would also eliminate option 2, because it seems clear=20 >> from evidence presented to date that any SIP method that is=20 >> conformant with normal SIP rules will have a significant impact on=20 >> scalability. >> >> John >> >>> -----Original Message----- >>> From: Christian Jansson [mailto:christian.jansson@hotsip.com] >>> Sent: 17 March 2006 09:49 >>> To: Samir Srivastava; Cullen Jennings; Christer Holmberg (JO/LMF);=20 >>> Hisham Khartabil; sip@ietf.org >>> Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN=20 >>> requestprocessingfaster than a SIP PING request processing? >>> >>>> Samir wrote: >>>> STUN with magic binary cookie is hack too.That looks to me >> going back >>>> to binary protocols and defeating the purpose of text based SIP=20 >>>> protocol. >>> So in principal you rather have something that is human >> readable than >>> something that works better in reality? >>> >>> >>>> Another point "Every application protocol should take of its own=20 >>>> mess using its own primitives" . >>> You mean we should for example also use SIP instead of DNS, >> DHCP, and >>> RTP? In general I think it is better to use a tool that is designed=20 >>> for the problem. >>> >>>> Within SIP too all headers doesn't >>>> apply to all methods, we are doing this to achive the performance. >>> SIP parsing and performance are not optimized, that is a >> fact. SIP and >>> human readability on the other hand... but who cares. >>> >>>> So PING is lesser evil than STUN. >>> If PING was SIP I would have no problem with it, but as it >> is defined >>> right now PING is not SIP even though the draft wants it to >> be. And I >>> do not think we should standardize things that are plain wrong just=20 >>> because it for the moment does not seem to introduce any enormous=20 >>> problems. >>> >>> I think we have 3 real options: >>> 1. Double CRLF >>> 2. A new real SIP method >>> 3. STUN >>> >>> Bad ideas: >>> 4. Using OPTIONS is a bad idea as it has another purpose, and adding >>> new method would cost us nothing and it would be very clear >> what was going >>> on. >>> 5. Using PING as it is being discussed right now is not an option as >>> long as it is not SIP as it claims to be. I do not want to see any=20 >>> more discussions of non-SIP things that just looks like SIP anymore. >>> >>> / Christian Jansson >>> >>> >>> _______________________________________________ >>> 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 application 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 >> >> >=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 Sun Mar 19 16:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL5n8-0007DX-Am; Sun, 19 Mar 2006 16:50:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL5n6-0007DP-TE for sip@ietf.org; Sun, 19 Mar 2006 16:50:24 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL5n2-0003ol-DX for sip@ietf.org; Sun, 19 Mar 2006 16:50:24 -0500 Received: from [130.129.134.205] (helo=[130.129.134.205]) by dns.aliantmedia.net with esmtpa (Exim 4.52) id 1FL5n0-00033q-FF; Sun, 19 Mar 2006 15:50:18 -0600 Message-ID: <441DD219.4030704@ntt-at.com> Date: Sun, 19 Mar 2006 13:50:17 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: sip@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: jmpolk@cisco.com, jon.peterson@neustar.biz, Hannes.Tschofenig@siemens.com Subject: [Sip] Re: I-D ACTION:draft-tschofenig-sip-saml-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 Hi Hannes and Jon; I really like the framework defined in the new draft, especially how you tried to tie the SAML asserting server(entity) with Authentication Server from SIP-Identity, it is so much more simple now. Reading through the drafts I find some concerns, question. - Concerns - 1). Certificate being inside an assertion. > This might be simply me being ignorant and not understanding SIP-Identity, but as I recall, Identity-Info defined in SIP-Identity is supposed to be pointing at the domain certificate itself, so I believe implementation that's supporting SIP-Identity is likely to choke, when it obtains an assertion which includes the domain certificate instead. > I guess you need to either update SIP-Identity to describe the possibility of domain certificate being embedded within the assertion or define a new header. > Also, caching the domain certificate will be difficult, if the caching is done based on the URI presented in the identity-info. As I understand with the SAML draft, identity-info is likely to change its URI depending on the caller and possibly depending on the timing of the call. Although I don't see this as an issue. 2). Name-Id Format > I think new Name-Id Format needs to be defined for SIP. Currently the example holds SIP address as an e-mail address. 3). Guideline > It would be very nice to provide a guideline on how one might be able to define a new profile or extend the current profile with more attributes. > I see that it's complicated as we are trying to use standard defined in another body, but it would be nice if it can be sorted out to define a guideline for that. Question. 1). Have you considered carrying the URI pointing to user's certificate in SAML? It might be nice to carry all the security attributes in SAML. Thanks & Regards Shida Schubert > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SIP SAML Profile and Binding > Author(s) : H. Tschofenig, et al. > Filename : draft-tschofenig-sip-saml-05.txt > Pages : 43 > Date : 2006-3-8 > > This document specifies a Session Initiation Protocol (SIP) profile > of Security Assertion Markup Language (SAML) as well as a SAML SIP > binding. The defined SIP SAML Profile composes with the mechanisms > defined in the SIP Identity specification and satisfy requirements > presented in "Trait-based Authorization Requirements for the Session > Initiation Protocol (SIP)". > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-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-tschofenig-sip-saml-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-tschofenig-sip-saml-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. > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-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 Sun Mar 19 17:10:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL64M-0003pn-G8; Sun, 19 Mar 2006 17:08:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL64K-0003pi-S5 for sip@ietf.org; Sun, 19 Mar 2006 17:08:12 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL64K-0004h8-3y for sip@ietf.org; Sun, 19 Mar 2006 17:08:12 -0500 Received: (qmail 4140 invoked by uid 0); 19 Mar 2006 22:08:09 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 19 Mar 2006 22:08:09 -0000 Message-ID: <00ac01c64ba1$986ff610$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Samir Srivastava" , "Aki Niemi" , "Francois Audet" References: <62B9B0847CC47543B6B3B5E26BD268E60AF53B69@zrc2hxm2.corp.nortel.com> Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? Date: Sun, 19 Mar 2006 23:05:43 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: Cullen Jennings , sip@ietf.org, "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 Samir, So in summary, you are saying "Since SIP MIB only supports statistics for SIP messages (and not per port), we should use SIP messages for keep-alive". I would argue the other way around: If it is a requirement for SIP MIB to collect statistics for overload analysis, it may need to take into account more than only SIP messages, and may also need to provide per-port statistics Regards, Jeroen ----- Original Message ----- From: "Samir Srivastava" To: "Aki Niemi" ; "Francois Audet" Cc: "Cullen Jennings" ; ; "Christer Holmberg (JO/LMF)" ; "Elwell, John" Sent: Sunday, March 19, 2006 10:43 PM Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN requestprocessingfaste r than a SIP PING request processing? Major portion of Overload and Congestion handling should be done in *out-of-band* manner. Handling most of that on the same signaling ( already overloaded/congested ) channel is architecturally incorrect, though there can be some SIP signaling messages for it. That's where SIP MIB comes into the picture. Overload / Congestion compliance will make more vendors to implement SIP MIB, which is of low traction currently. SIP MIB captures the stats per method basis. It will be easy to extend it for PING and find out the PING load (Which is a lot, refer Jonathan' email link) in out-of-band manner. Finding STUN keep alive load using MIB-II objects is not possible. MIB-II objects doesn't have per port stats. There counters are transport protocol based. So it will not be possible to catch CRLF stats from there. Choices are :- 1) Extend MIB II to have per port basis stats. Which is not a available route as SIP needs granular stats it better should have in its own MIB. 2) Treat STUN CRLF keep alive as SIP method for stats capturing (Bad design). 3) Have PING method (which purist doesn't like). IMHO 3) is best among the *available* choices for overload and congestion problem to be addressed in future. Thx Samir -----Original Message----- From: Aki Niemi [mailto:aki.niemi@nokia.com] Sent: Sunday, March 19, 2006 7:50 AM To: Audet, Francois [SC100:3055:EXCH] Cc: Elwell, John; Christian Jansson; Srivastava, Samir [SC100:8826:EXCH]; Cullen Jennings; Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? I agree. Pekka Pessi explained the issue already much better than I ever could: http://www1.ietf.org/mail-archive/web/sip/current/msg12841.html In summary: processing STUN and, say, OPTIONS consumes roughly the same amount of packets on-the-wire, system calls and both parsers (alone) fit in modern processor caches. So the bottleneck is somewhere else than in CPU, like in memory bus or network I/O. (This might actually be worse for a combined SIP+STUN parser, but I don't have concrete data on that unfortunately.) To which Jonathan replied that bandwidth is also an issue to consider, and would favor a protocol that was smaller on the wire: http://www1.ietf.org/mail-archive/web/sip/current/msg12842.html However, the data Jonathan presented assumes a proxy that only sees VoIP traffic. I don't think you can restrict "useful traffic" to VoIP only. If you take a proxy that not only sees INVITE/200/ACK, but presence and IM as well, the numbers change. I recently saw numbers from a real deployment that accounted almost 90% of the messages seen by proxies to be presence related; VoIP only accounted for approximately 6% of messages. The graphs didn't show bandwidth figures, but I'd expect them to be ever worse. Cheers, Aki ext Francois Audet wrote: > Actually, the evidence presented so far pointed to the opposite, i.e., > that a new method was actually slightly less resource intensive than > STUN. > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Friday, March 17, 2006 05:57 >> To: Christian Jansson; Srivastava, Samir [SC100:8826:EXCH]; Cullen >> Jennings; Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org >> Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN >> requestprocessingfaste r than a SIP PING request processing? >> >> >> Christian, >> >> I agree, and I would also eliminate option 2, because it seems clear >> from evidence presented to date that any SIP method that is >> conformant with normal SIP rules will have a significant impact on >> scalability. >> >> John >> >>> -----Original Message----- >>> From: Christian Jansson [mailto:christian.jansson@hotsip.com] >>> Sent: 17 March 2006 09:49 >>> To: Samir Srivastava; Cullen Jennings; Christer Holmberg (JO/LMF); >>> Hisham Khartabil; sip@ietf.org >>> Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN >>> requestprocessingfaster than a SIP PING request processing? >>> >>>> Samir wrote: >>>> STUN with magic binary cookie is hack too.That looks to me >> going back >>>> to binary protocols and defeating the purpose of text based SIP >>>> protocol. >>> So in principal you rather have something that is human >> readable than >>> something that works better in reality? >>> >>> >>>> Another point "Every application protocol should take of its own >>>> mess using its own primitives" . >>> You mean we should for example also use SIP instead of DNS, >> DHCP, and >>> RTP? In general I think it is better to use a tool that is designed >>> for the problem. >>> >>>> Within SIP too all headers doesn't >>>> apply to all methods, we are doing this to achive the performance. >>> SIP parsing and performance are not optimized, that is a >> fact. SIP and >>> human readability on the other hand... but who cares. >>> >>>> So PING is lesser evil than STUN. >>> If PING was SIP I would have no problem with it, but as it >> is defined >>> right now PING is not SIP even though the draft wants it to >> be. And I >>> do not think we should standardize things that are plain wrong just >>> because it for the moment does not seem to introduce any enormous >>> problems. >>> >>> I think we have 3 real options: >>> 1. Double CRLF >>> 2. A new real SIP method >>> 3. STUN >>> >>> Bad ideas: >>> 4. Using OPTIONS is a bad idea as it has another purpose, and adding >>> new method would cost us nothing and it would be very clear >> what was going >>> on. >>> 5. Using PING as it is being discussed right now is not an option as >>> long as it is not SIP as it claims to be. I do not want to see any >>> more discussions of non-SIP things that just looks like SIP anymore. >>> >>> / Christian Jansson >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on >> current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 19 17:54:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6lK-0000Mc-9d; Sun, 19 Mar 2006 17:52:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6lI-0000KT-Tr for sip@ietf.org; Sun, 19 Mar 2006 17:52:36 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL6lH-0006Jc-Hj for sip@ietf.org; Sun, 19 Mar 2006 17:52:36 -0500 Received: from [204.96.114.213] ([204.96.114.213]) by server (8.12.8/8.12.8) with SMTP id k2JLPU2x031872 for ; Sun, 19 Mar 2006 16:25:37 -0500 Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <4a5baf441362aa277098765f92c7ffa4@telio.no> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "sip@ietf.org List" From: Hisham Khartabil Date: Sun, 19 Mar 2006 23:52:59 +0100 X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] voicemail-uri: UAS sending 302 or 486 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Apologies for the very late comments/questions. This question is probably not related to the voicemail-uri draft itself, but the examples got me a little confused Example 6.1 shows Bob sending a 486 while in example 6.2 Bob is sending a 302. Just a couple of questions: - How does Bob know when to send a 486 and when to send a 302? - What if in example 6.2 the proxy recurses on 3xx responses? Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 19 20:34:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL9GI-0007U1-2i; Sun, 19 Mar 2006 20:32:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL9GH-0007OG-7Y for sip@ietf.org; Sun, 19 Mar 2006 20:32:45 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL9GF-0003VO-SW for sip@ietf.org; Sun, 19 Mar 2006 20:32:45 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 318CF13F98A; Mon, 20 Mar 2006 03:32:42 +0200 (EET) Received: from rautu (host78-195.kawanuanet.net.id [202.78.195.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 9565A13F97F; Mon, 20 Mar 2006 03:32:36 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 67B4BF027F; Mon, 20 Mar 2006 03:33:00 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17438.1612.319980.971234@rautu.tutpro.com> Date: Mon, 20 Mar 2006 03:33:00 +0200 From: Juha Heinanen To: "Drage, Keith (Keith)" Subject: RE: [Sip] The Problem with PRACK In-Reply-To: <475FF955A05DD411980D00508B6D5FB0127488E2@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0127488E2@en0033exch001u.uk.lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Drage, Keith (Keith) writes: > Moreover the argument Juha was developing was that we have have a > technical solution that would appear to preclude charging for > allocated resource at the user access on a per session basis. i'm tired of this bull-you-know. i specifically showed that SIP UAC and UAS can allocated access bandwidth for a call without ANYTHING new to rfc3261. and if UAC and UAS can allocate access resources, sure someone in the access network can charge for them. -- 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 Sun Mar 19 21:59:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAaF-0006Yj-1o; Sun, 19 Mar 2006 21:57:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAaD-0006YY-0t for sip@ietf.org; Sun, 19 Mar 2006 21:57:25 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLAaC-0005oe-JV for sip@ietf.org; Sun, 19 Mar 2006 21:57:25 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2K2tEjJ009684; Mon, 20 Mar 2006 04:55:14 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 04:57:23 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 04:57:23 +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] The Problem with PRACK Date: Mon, 20 Mar 2006 04:57:21 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02165C38@esebe103.NOE.Nokia.com> In-Reply-To: <17438.1612.319980.971234@rautu.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZLvm+3PQQwch/nSeOgC1AyTO1+EQACHTUw From: To: , X-OriginalArrivalTime: 20 Mar 2006 02:57:23.0748 (UTC) FILETIME=[034CCE40:01C64BCA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 >i'm tired of this bull-you-know.=20 Sorry Juha to bother you still once more, but Adam's comments indicate the issue as serious ... > I'll point out that implementing the offer/answer procedures with PRACK > requires a state machine with at least 52 states and 329 transitions. > That's a *lot* of code, and the chances of getting it all right are > pretty close to zero. ... so I would still like to understand the subject a bit better. In your story there is something that does not yet make sense to me. You have suggested the following: - Preconditions and PRACK have been specified for 3GPP requirements - You do not have any business for 3GPP environment - Your customers have bought lots of SIP phones with PRACK implementation (with offer/answer if I understand you correctly) So do you have any idea, why those SIP phones used in non-3gpp environment have implemented PRACK which has caused so much problems ? I do not believe they have added PRACK support=20 - just to cause problems and make call setup to take longer - to have some programming fun with an interesting piece of RFC - for 3GPP IMS compliancy - I understood it is not their business It would be good to understand why such implementations exist in wireline SIP environment. If that is not well understood we do not know what implications might deprecating offer/answer within PRACK to have and what kind of solutions would be needed in place of that. Do those wireline SIP phones try to do preconditions or something else with PRACK ? If they do preconditions, what kind of (security, resource reservation) ? What is the motivation for all that in your business environment ? Regards, Erkki ____________________________________ Erkki Koivusalo Nokia Mobile Software tel:+358 40 7571197 mailto:erkki.koivusalo@nokia.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 From sip-bounces@ietf.org Sun Mar 19 22:23:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAxM-0004JN-KZ; Sun, 19 Mar 2006 22:21:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAxL-0004JI-BQ for sip@ietf.org; Sun, 19 Mar 2006 22:21:19 -0500 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLAxK-0006Wo-SA for sip@ietf.org; Sun, 19 Mar 2006 22:21:19 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2K3LED29081; Sun, 19 Mar 2006 22:21:14 -0500 (EST) 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] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sun, 19 Mar 2006 21:21:11 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60AF53C17@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? Thread-Index: AcZLoaBLrH+i32ttS4um4J4WGHwU/gAJzIpw From: "Samir Srivastava" To: "Jeroen van Bemmel" , "Aki Niemi" , "Francois Audet" X-Spam-Score: 0.1 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: Cullen Jennings , sip@ietf.org, "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 Hi Jeroen, I understand your concerns that SIP MIB should not be constraint in implementing optimized signaling features. I am just trying to see how it will fit in the forthcoming overload/congestion solutions.=20 SIP MIB has applIndex also, which looks to me SIP Server / Port. Excuse my less knowledge of SIP MIB. It captures the SIP method stats per method and per application. SIP MIB authors pl comment. My requirement is, I need to find out the KEEP ALIVE traffic in MIB. CR-LF is not a SIP method, So it's stat will not captured there. And I don't have any way to find out that using existing MIB's. There is one more available choice. I am listing all below again for the feedback=20 1) Define STUN MIB. (Does it exist, I don't see it on the behave page) Should be taken in behave. If there is enough momentum from other STUN users, then it is worth taking it. Design wise, it is right place to capture CR-LF stats. I have another fundamental design issue, STUN MIB needs to able differentiate SIP port NAT binding Keep Alive traffic from other STUN traffic. It will be taking more time in developing new MIB, and SIP overload / congestion framework will be dependent on that too. 2) Extend MIB II to have per port basis stats. Which is not a available route as SIP needs granular stats it better should have in its own MIB. 3) Treat STUN CRLF keep alive as SIP method for stats capturing (Bad design). 4) Have PING method (which purist doesn't like) but it can be done with least pain and quickly. Thx Samir -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: Sunday, March 19, 2006 2:06 PM To: Srivastava, Samir [SC100:8826:EXCH]; Aki Niemi; Audet, Francois [SC100:3055:EXCH] Cc: Cullen Jennings; sip@ietf.org; Christer Holmberg (JO/LMF); Elwell, John Subject: Re: [Sip] Myth Busters: Episode 1,Is STUN requestprocessingfaste r than a SIP PING request processing? Samir, So in summary, you are saying "Since SIP MIB only supports statistics for SIP messages (and not per port), we should use SIP messages for keep-alive". I would argue the other way around: If it is a requirement for SIP MIB to collect statistics for overload analysis, it may need to take into account more than only SIP messages, and may also need to provide per-port statistics Regards, Jeroen ----- Original Message ----- From: "Samir Srivastava" To: "Aki Niemi" ; "Francois Audet" Cc: "Cullen Jennings" ; ; "Christer Holmberg (JO/LMF)" ; "Elwell, John"=20 Sent: Sunday, March 19, 2006 10:43 PM Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN requestprocessingfaste r than a SIP PING request processing? Major portion of Overload and Congestion handling should be done in *out-of-band* manner. Handling most of that on the same signaling ( already overloaded/congested ) channel is architecturally incorrect, though there can be some SIP signaling messages for it. That's where SIP MIB comes into the picture. Overload / Congestion compliance will make more vendors to implement SIP MIB, which is of low traction currently. SIP MIB captures the stats per method basis. It will be easy to extend it for PING and find out the PING load (Which is a lot, refer Jonathan' email link) in out-of-band manner. Finding STUN keep alive load using MIB-II objects is not possible. MIB-II objects doesn't have per port stats. There counters are transport protocol based. So it will not be possible to catch CRLF stats from there. Choices are :- 1) Extend MIB II to have per port basis stats. Which is not a available route as SIP needs granular stats it better should have in its own MIB. 2) Treat STUN CRLF keep alive as SIP method for stats capturing (Bad design). 3) Have PING method (which purist doesn't like). IMHO 3) is best among the *available* choices for overload and congestion problem to be addressed in future. Thx Samir -----Original Message----- From: Aki Niemi [mailto:aki.niemi@nokia.com] Sent: Sunday, March 19, 2006 7:50 AM To: Audet, Francois [SC100:3055:EXCH] Cc: Elwell, John; Christian Jansson; Srivastava, Samir [SC100:8826:EXCH]; Cullen Jennings; Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing? I agree. Pekka Pessi explained the issue already much better than I ever could: http://www1.ietf.org/mail-archive/web/sip/current/msg12841.html In summary: processing STUN and, say, OPTIONS consumes roughly the same amount of packets on-the-wire, system calls and both parsers (alone) fit in modern processor caches. So the bottleneck is somewhere else than in CPU, like in memory bus or network I/O. (This might actually be worse for a combined SIP+STUN parser, but I don't have concrete data on that unfortunately.) To which Jonathan replied that bandwidth is also an issue to consider, and would favor a protocol that was smaller on the wire: http://www1.ietf.org/mail-archive/web/sip/current/msg12842.html However, the data Jonathan presented assumes a proxy that only sees VoIP traffic. I don't think you can restrict "useful traffic" to VoIP only. If you take a proxy that not only sees INVITE/200/ACK, but presence and IM as well, the numbers change. I recently saw numbers from a real deployment that accounted almost 90% of the messages seen by proxies to be presence related; VoIP only accounted for approximately 6% of messages. The graphs didn't show bandwidth figures, but I'd expect them to be ever worse. Cheers, Aki ext Francois Audet wrote: > Actually, the evidence presented so far pointed to the opposite, i.e., > that a new method was actually slightly less resource intensive than=20 > STUN. > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Friday, March 17, 2006 05:57 >> To: Christian Jansson; Srivastava, Samir [SC100:8826:EXCH]; Cullen=20 >> Jennings; Christer Holmberg (JO/LMF); Hisham Khartabil; sip@ietf.org >> Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN=20 >> requestprocessingfaste r than a SIP PING request processing? >> >> >> Christian, >> >> I agree, and I would also eliminate option 2, because it seems clear=20 >> from evidence presented to date that any SIP method that is=20 >> conformant with normal SIP rules will have a significant impact on=20 >> scalability. >> >> John >> >>> -----Original Message----- >>> From: Christian Jansson [mailto:christian.jansson@hotsip.com] >>> Sent: 17 March 2006 09:49 >>> To: Samir Srivastava; Cullen Jennings; Christer Holmberg (JO/LMF);=20 >>> Hisham Khartabil; sip@ietf.org >>> Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN=20 >>> requestprocessingfaster than a SIP PING request processing? >>> >>>> Samir wrote: >>>> STUN with magic binary cookie is hack too.That looks to me >> going back >>>> to binary protocols and defeating the purpose of text based SIP=20 >>>> protocol. >>> So in principal you rather have something that is human >> readable than >>> something that works better in reality? >>> >>> >>>> Another point "Every application protocol should take of its own=20 >>>> mess using its own primitives" . >>> You mean we should for example also use SIP instead of DNS, >> DHCP, and >>> RTP? In general I think it is better to use a tool that is designed=20 >>> for the problem. >>> >>>> Within SIP too all headers doesn't >>>> apply to all methods, we are doing this to achive the performance. >>> SIP parsing and performance are not optimized, that is a >> fact. SIP and >>> human readability on the other hand... but who cares. >>> >>>> So PING is lesser evil than STUN. >>> If PING was SIP I would have no problem with it, but as it >> is defined >>> right now PING is not SIP even though the draft wants it to >> be. And I >>> do not think we should standardize things that are plain wrong just=20 >>> because it for the moment does not seem to introduce any enormous=20 >>> problems. >>> >>> I think we have 3 real options: >>> 1. Double CRLF >>> 2. A new real SIP method >>> 3. STUN >>> >>> Bad ideas: >>> 4. Using OPTIONS is a bad idea as it has another purpose, and adding >>> new method would cost us nothing and it would be very clear >> what was going >>> on. >>> 5. Using PING as it is being discussed right now is not an option as >>> long as it is not SIP as it claims to be. I do not want to see any=20 >>> more discussions of non-SIP things that just looks like SIP anymore. >>> >>> / Christian Jansson >>> >>> >>> _______________________________________________ >>> 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 application 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=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=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 Mar 20 01:28:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLDq5-0005vt-Or; Mon, 20 Mar 2006 01:26:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLDq3-0005vo-7H for sip@ietf.org; Mon, 20 Mar 2006 01:25:59 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLDq1-0004CI-RG for sip@ietf.org; Mon, 20 Mar 2006 01:25:59 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2K6PlZe010288; Mon, 20 Mar 2006 00:25:48 -0600 (CST) Received: from [135.255.30.109] (vkg.lra.lucent.com [135.255.30.109]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2K6PjC18231; Mon, 20 Mar 2006 00:25:45 -0600 (CST) Message-ID: <441E4AEB.7020904@lucent.com> Date: Mon, 20 Mar 2006 00:25:47 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com Subject: Re: [Sip] Re: Comments to sip-outbound References: <441AD027.6030801@nokia.com><39229.12.151.41.2.1142614255.squirrel@12.151.41.2><441D7166.6030503@nokia.com> <24c93c1352cd57bde4924ff3309802f6@ekabal.com> <009001c64b80$bfb40160$31713b51@BEMBUSTER> <441DAB0F.9060105@nokia.com> In-Reply-To: <441DAB0F.9060105@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, rohan@ekabal.com, fluffy@cisco.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 Aki Niemi wrote: > But another thing occurred to me about the use of TCP keepalives. Since > they are only hop-by-hop, they may not guarantee a flow is alive in the > presence of proxy or proxies in the path to a registrar. At least not in > the same way a CRLFx2 would. True; this has been the traditional rub against TCP keepalives. If an intermediary (router) is down but the endpoints are up, the endpoints may erroneously tear the connection down based on this information (Unix Network Prorgamming by Fenner et al. discusses this, as did the older TCP/IP Illustrated by W. Richard Stevens). What has been interesting about Jeroen's experiments has been the fact that the keepalive is now supported on a per connection basis. Even the last authoritative book on this subject (according to me), "Unix Network Programming: The Sockets Networking API" by Fenner et al. (Nov 2003) makes reference to the fact that keepalive value is system-wide, not per connection. It appears that some modern operating systems have started to support keepalives at the per- connection level, but this support is not as yet universal (I don't know whether it is driven by the tcpm WG in the TSV area). One more observation: if the intent is to ensure that the peer is still alive, one can do so by simply monitoring certain exceptional events on the socket. For instance, if one end of the connection crashes (i.e., the peer crashes, but the host is up), the other end's TCP will receive a RST (Fenner et al.'s book mentions this). But, if the host on which a peer runs is made unavailable (cable pulled out, its default router being down, etc.) then the other peer will obviously not receive anything, not even a RST. So certain cases in outbound can be supported through normal programming tricks, without even resorting to CRLFx2. It is the remaining cases which will cause headaches. 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 Mon Mar 20 01:43:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLE58-0005kt-VN; Mon, 20 Mar 2006 01:41:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLE56-0005iM-Lw for sip@ietf.org; Mon, 20 Mar 2006 01:41:32 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLE54-0004ju-9m for sip@ietf.org; Mon, 20 Mar 2006 01:41:32 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Mar 2006 01:41:30 -0500 X-IronPort-AV: i="4.03,110,1141621200"; d="scan'208"; a="84494559:sNHT31088128" 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 k2K6fTWc002976 for ; Mon, 20 Mar 2006 01:41:30 -0500 (EST) 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.211); Mon, 20 Mar 2006 01:41:29 -0500 Received: from [130.129.128.208] ([10.86.240.60]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 01:41:29 -0500 Message-ID: <441E4E99.5090705@cisco.com> Date: Mon, 20 Mar 2006 01:41:29 -0500 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: 20 Mar 2006 06:41:29.0592 (UTC) FILETIME=[51A5C780:01C64BE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Sip] comments on location conveyance 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 I gave this a quick read. Some high level comments: * The spec defines two option tags - location and unknown-location. The latter (I think) implies that the extension is supported but no location is being provided. This is really a misuse of option tags. Option tags merely convey whether a specification is supported or not. If you want to indicate that the extension is supported but no location is provided, then include Supported:location and omit the Location header field * sometimes the draft talks about the option tags being used in Supported/Unsupported, and sometimes in the Location header field itself. This makes no sense; option tags should be used as part of the Supported/Unsupported/Require header field. What would the semantic be of an option tag in Location? * The new 424 response code defined in section 4.2 doesn't talk about usage of Unsupported in the resonse, but the examples in the document include it. However, its not supposed to be used this way. Unsupported is supposed to be used in a 420 error response, as a consequence of a Require header field in a request. 424 is generated only when the UAS understands the extension, so it doesn't make sense to use it this way. * The draft, though shorter than previous versions, seems still far longer than it needs to be. It has lots of examples, one for each method which might be used. As draft-ietf-sip-guidelines explains, normative specs are just supposed to have a single example or two. The numerous examples here do not lend to clarity * The draft is missing a basic overview of operation section (also required by sip-guidelines) * Its not clear to me that 424 is really useful; there are no remedies that can be invoked by the UAC, and the draft doesn't define the conditions under which it would be sent. How, then, does the system behavior differ if a simple 400 is used instead? * You don't define a mandatory-to-implement URI scheme for obtaining location-by-reference. You need to do that, along with any other constraints on the URI (secure or not? mandatory content types? etc.) * The document talks about the Requires header field - its Require * The Location syntax allows for a token or quoted string value; but this is not discussed as to what it would mean * This paragraph seems contradictory: It is RECOMMENDED that only one Location header be in the same message, but this is not mandatory. That said, there MUST NOT be more than one cid-url pointing to a location message body (part) in a SIP message, regardless of how many Location headers there are in that message. There MUST NOT be more than one location by-reference URI in any SIP message, regardless of how many Location headers there are in a message. Why have more than one Location (btw, there is just a single header field - it would have multiple values), if you can't have more than one cid-url or location-by-reference? * This is incorrect application of rfc2119 language: The SIP Request Methods that MUST convey location are the INVITE, REGISTER, UPDATE and MESSAGE Methods. It is not forbidden by this MUST/MAY/SHOUDL specify requirements for implementors. You are writing this as a requirement for the specification; one that is met by the specification itslef in any case. 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 Mon Mar 20 02:32:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLEql-0000jW-Nk; Mon, 20 Mar 2006 02:30:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLEqb-0000Cj-TY for sip@ietf.org; Mon, 20 Mar 2006 02:30:37 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLEbV-000636-NB for sip@ietf.org; Mon, 20 Mar 2006 02:15:05 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 19 Mar 2006 23:15:01 -0800 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 k2K7F1Gv000196 for ; Sun, 19 Mar 2006 23:15:01 -0800 (PST) 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.211); Sun, 19 Mar 2006 23:15:01 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.120.59]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Mar 2006 23:15:00 -0800 Message-Id: <4.3.2.7.2.20060320005532.019621d0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Mar 2006 01:14:58 -0600 To: Jonathan Rosenberg , IETF SIP List From: "James M. Polk" Subject: Re: [Sip] comments on location conveyance draft In-Reply-To: <441E4E99.5090705@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Mar 2006 07:15:00.0640 (UTC) FILETIME=[00535A00:01C64BEE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 Jonathan thanks for the review comments in-line At 01:41 AM 3/20/2006 -0500, Jonathan Rosenberg wrote: >I gave this a quick read. Some high level comments: > >* The spec defines two option tags - location and unknown-location. The >latter (I think) implies that the extension is supported but no location >is being provided. This is really a misuse of option tags. I knew I was stretching the use here (see below) >Option tags merely convey whether a specification is supported or not. If >you want to indicate that the extension is supported but no location is >provided, then include Supported:location and omit the Location header field this is fine with me, as if there is location by-reference, the location header would need to be there with the location URI, and if there is location by-value, the location header would need to be there with the cid: value of which message body part is carrying the PIDF-LO. >* sometimes the draft talks about the option tags being used in >Supported/Unsupported, and sometimes in the Location header field itself. >This makes no sense; option tags should be used as part of the >Supported/Unsupported/Require header field. What would the semantic be of >an option tag in Location? Removing the Unknown-Location option-tag (agreed to above) removes this issue completely. >* The new 424 response code defined in section 4.2 doesn't talk about >usage of Unsupported in the resonse, but the examples in the document >include it. However, its not supposed to be used this way. Unsupported is >supposed to be used in a 420 error response, as a consequence of a Require >header field in a request. 424 is generated only when the UAS understands >the extension, so it doesn't make sense to use it this way. I will correct this >* The draft, though shorter than previous versions, seems still far longer >than it needs to be. It has lots of examples, one for each method which >might be used. As draft-ietf-sip-guidelines explains, normative specs are >just supposed to have a single example or two. The numerous examples here >do not lend to clarity hmmm.... I agree that there are a number of examples, including at least one per method. I will look to see where I can cut down the number further still. >* The draft is missing a basic overview of operation section (also >required by sip-guidelines) I consider the operation to be there in section 4, but I may be overlooking the simplicity that is needed in such a section. >* Its not clear to me that 424 is really useful; there are no remedies >that can be invoked by the UAC, and the draft doesn't define the >conditions under which it would be sent. How, then, does the system >behavior differ if a simple 400 is used instead? I expect that if a UAC receives a 424, it knows its location was not understood, and to refresh its location, however it got it in the first place *or* attempt to fetch its location from a secondary source, and send a subsequent SIP message. I was leary of putting in this non-SIP text, but I can easily. >* You don't define a mandatory-to-implement URI scheme for obtaining >location-by-reference. You need to do that, along with any other >constraints on the URI (secure or not? mandatory content types? etc.) ok >* The document talks about the Requires header field - its Require sorry >* The Location syntax allows for a token or quoted string value; but this >is not discussed as to what it would mean I already know to fix this >* This paragraph seems contradictory: > > It is RECOMMENDED that only one Location header be in the same > message, but this is not mandatory. That said, there MUST NOT be > more than one cid-url pointing to a location message body (part) in > a SIP message, regardless of how many Location headers there are in > that message. There MUST NOT be more than one location by-reference > URI in any SIP message, regardless of how many Location headers > there are in a message. > > >Why have more than one Location (btw, there is just a single header field >- it would have multiple values), if you can't have more than one cid-url >or location-by-reference? the issue with all this is having more than one pointer to different locations. A UAS would not know which is valid for the UAC. A PIDF-LO as an identity of the device, meaning, if there are two, there would be two devices at two locations. This is complicated further by a UAC that S/MIME encrypts a PIDF-LO, and a SIP Server, not aware the message had location, adding a Location header which pointed at another position for that UAC. I will work on this explanation in the section >* This is incorrect application of rfc2119 language: > > The SIP Request Methods that MUST convey location are the INVITE, > REGISTER, UPDATE and MESSAGE Methods. It is not forbidden by this > > >MUST/MAY/SHOUDL specify requirements for implementors. You are writing >this as a requirement for the specification; one that is met by the >specification itslef in any case. I will correct this >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 From sip-bounces@ietf.org Mon Mar 20 02:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLEzM-0006sy-Uc; Mon, 20 Mar 2006 02:39:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLEzL-0006so-1h for sip@ietf.org; Mon, 20 Mar 2006 02:39:39 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLEzH-0006ud-7q for sip@ietf.org; Mon, 20 Mar 2006 02:39:39 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 760284F0001; Mon, 20 Mar 2006 08:39:34 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 08:39:34 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 08:39:34 +0100 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] The Problem with PRACK Date: Mon, 20 Mar 2006 08:39:33 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B6F@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZLvm+3PQQwch/nSeOgC1AyTO1+EQACHTUwAAnDGxA= From: "Christer Holmberg \(JO/LMF\)" To: , , X-OriginalArrivalTime: 20 Mar 2006 07:39:34.0149 (UTC) FILETIME=[6E9AFB50:01C64BF1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 have never seen a commercial non-IMS terminal supporting the pre-conditions mechanism - not as a UAC, and not as a UAS. I have seen commercial non-IMS terminals supporting PRACK - for acknowledgement of reliable provisional responses, and as far as I know that normally works quite well (and if we could get rid of the queing I think it would even work better).=20 SOME of the those PRACK supporting terminals may be able to process an SDP offer RECEIVED in a PRACK, but I doubt many would actually SEND an offer in a PRACK. They probably also have different ways of rejecting an SDP offer received in a PRACK, because there is no standardized way of doing it (I don't buy the argument that "it never needs to be done"). However, this is just my personal view of the world, so others may of course have another opinion. Regards, Christer =20 -----Original Message----- From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 Sent: 20. maaliskuuta 2006 4:57 To: jh@tutpro.com; drage@lucent.com Cc: sip@ietf.org Subject: RE: [Sip] The Problem with PRACK Hi,=20 >i'm tired of this bull-you-know.=20 Sorry Juha to bother you still once more, but Adam's comments indicate the issue as serious ... > I'll point out that implementing the offer/answer procedures with PRACK > requires a state machine with at least 52 states and 329 transitions. > That's a *lot* of code, and the chances of getting it all right are=20 > pretty close to zero. ... so I would still like to understand the subject a bit better. In your story there is something that does not yet make sense to me. You have suggested the following: - Preconditions and PRACK have been specified for 3GPP requirements - You do not have any business for 3GPP environment - Your customers have bought lots of SIP phones with PRACK implementation (with offer/answer if I understand you correctly) So do you have any idea, why those SIP phones used in non-3gpp environment have implemented PRACK which has caused so much problems ? I do not believe they have added PRACK support=20 - just to cause problems and make call setup to take longer - to have some programming fun with an interesting piece of RFC - for 3GPP IMS compliancy - I understood it is not their business It would be good to understand why such implementations exist in wireline SIP environment. If that is not well understood we do not know what implications might deprecating offer/answer within PRACK to have and what kind of solutions would be needed in place of that. Do those wireline SIP phones try to do preconditions or something else with PRACK ? If they do preconditions, what kind of (security, resource reservation) ? What is the motivation for all that in your business environment ? Regards, Erkki ____________________________________ Erkki Koivusalo Nokia Mobile Software tel:+358 40 7571197 mailto:erkki.koivusalo@nokia.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 From sip-bounces@ietf.org Mon Mar 20 03:08:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFPC-0005xZ-8O; Mon, 20 Mar 2006 03:06:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFPB-0005pA-5B for sip@ietf.org; Mon, 20 Mar 2006 03:06:21 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLFP8-0007dx-Na for sip@ietf.org; Mon, 20 Mar 2006 03:06:21 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k2K85mdL023756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Mar 2006 09:05:48 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k2K85hZe013650; Mon, 20 Mar 2006 09:05:43 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k2K85XS1013647; Mon, 20 Mar 2006 09:05:33 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] SBCs and draft-ietf-sip-identity-06 From: Hans Persson To: "sip@ietf.org" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Mon, 20 Mar 2006 09:05:33 +0100 Message-Id: <1142841933.12137.2.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Mon, 20 Mar 2006 09:05:48 +0100 (CET) X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Cullen Jennings , 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 fre 2006-03-17 klockan 15:51 -0600 skrev Dean Willis: > What if we extended the logic to be "Domain of the From: header must > match the domain of the certificate of the signer" OR "the > certificate of the signer MUST match the transitive trust domain of > the recipient"? That would take care of my concerns. Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 20 04:57:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLH6q-0003f6-6o; Mon, 20 Mar 2006 04:55:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLH6n-0003f1-Ui for sip@ietf.org; Mon, 20 Mar 2006 04:55:29 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLH6m-0003Cr-Eo for sip@ietf.org; Mon, 20 Mar 2006 04:55:29 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2K9tPNX019462; Mon, 20 Mar 2006 11:55:26 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 11:55:25 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 11:55:25 +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] The Problem with PRACK Date: Mon, 20 Mar 2006 11:55:24 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02165F19@esebe103.NOE.Nokia.com> In-Reply-To: <441B5AFF.2030909@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZKJyRnTJWBdX0pQfOp7P1eXqBLrwB23mQQ From: To: , X-OriginalArrivalTime: 20 Mar 2006 09:55:25.0269 (UTC) FILETIME=[690D3050:01C64C04] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 Hello, >In Vancouver, Rohan put up a slide to demonstrate this issue >graphically, but its impact hasn't been shared on the list. To=20 >that end, >I'll point out that implementing the offer/answer procedures with PRACK >requires a state machine with at least 52 states and 329 transitions. >That's a *lot* of code, and the chances of getting it all right are >pretty close to zero. If that is the case, I would really ask that slide with explanations to be published in SIP mailing list. For instance I was not attending Vancouver meeting, so I am currently lacking this piece of information. I would especially like to be explained where this multitude of states and transitions come from for sending offers/answers in PRACK, especially when compared to a solution where those could only be sent in UPDATE. My point is that only after understanding all that it would be possible to evaluate the effectivity of proposed simplifying solutions like the one Rohan has suggested. >> I went back over the 102 messages in this thread and did not hear any >> comments on my concrete proposals: >> : >> comments on *this*? > >Out of curiosity, did you go through the exercise of putting together an=20 >offer/answer state machine that takes this change into account? Is it=20 >much simpler?=20 In my understanding, for 3GPP the following three proposals would be OK: >> - require RSeq to start at 1 >> - only acknowledge the most recent provisional. if the UAS wants to=20 >> send as new provisional that completely replaces a previous one it can=20 >> send immediately. if the UAS wants to send a new provisional but=20 >> wants acknowledgement of a previous one, it has to wait for the PRACK. >> - send a provisional every 1 minute whether reliable or not. (instead=20 >> of every one minute for unreliable and every 2.5 minutes for reliable) but this last one would cause severe problems: >> - deprecate *offers* in PRACK (answers are still OK) I hope that we would be able to study the problem closer in order to find out if there still be some other kind of simplifications to be made, to get the state machinery smaller, while keeping the possibility of sending offers in PRACK. Full analysis is still to be done, but it would require the referred state machine to be scrutinized. Regards, Erkki >-----Original Message----- >From: ext Adam Roach [mailto:adam@nostrum.com]=20 >Sent: 18.March.2006 02:58 >To: Drage, Keith (Keith) >Cc: sip@ietf.org >Subject: Re: [Sip] The Problem with PRACK > >Drage, Keith (Keith) wrote: > >>If PRACK is bad, and I have not yet seen any technical=20 >evidence provided against it except that potentially it is=20 >hard to implement right... >> > >You miss the point. Calling PRACK "potentially hard to implement right" >is like referring to WWII as "a trifling difference of opinions." > >In Vancouver, Rohan put up a slide to demonstrate this issue >graphically, but its impact hasn't been shared on the list. To=20 >that end, >I'll point out that implementing the offer/answer procedures with PRACK >requires a state machine with at least 52 states and 329 transitions. >That's a *lot* of code, and the chances of getting it all right are >pretty close to zero. > >All of which makes me very skeptical of arguments that we can't change >PRACK because it has been widely implemented: I offer that it's highly >unlikely that it has been implemented correctly even once. > >/a > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 20 05:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLHY6-0003EX-Vd; Mon, 20 Mar 2006 05:23:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLHY5-0003EI-CR for sip@ietf.org; Mon, 20 Mar 2006 05:23:41 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLHY2-0004Er-TX for sip@ietf.org; Mon, 20 Mar 2006 05:23:41 -0500 Received: by tutpro.com (Postfix, from userid 33) id 37A5313F989; Mon, 20 Mar 2006 12:23:29 +0200 (EET) Received: from 203.117.181.40 (SquirrelMail authenticated user jh) by lohi.tutpro.com with HTTP; Mon, 20 Mar 2006 12:23:29 +0200 (EET) Message-ID: <63748.203.117.181.40.1142850209.squirrel@lohi.tutpro.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F02165C38@esebe103.NOE.Nokia.com> References: <17438.1612.319980.971234@rautu.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F02165C38@esebe103.NOE.Nokia.com> Date: Mon, 20 Mar 2006 12:23:29 +0200 (EET) Subject: RE: [Sip] The Problem with PRACK From: "Juha Heinanen" To: Erkki.Koivusalo@nokia.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org, jh@tutpro.com, drage@lucent.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jh@tutpro.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Erkki.Koivusalo@nokia.com said: > - Your customers have bought lots of SIP phones with PRACK > implementation > (with offer/answer if I understand you correctly) i don't know if with or w/o offer answer and i don't care. the thing tha= t i know is that when new software has come out, phones that used to interoperate well with others, stopped doing so. > So do you have any idea, why those SIP phones used in non-3gpp > environment > have implemented PRACK which has caused so much problems ? I do not > believe > they have added PRACK support. i have seen PRACK request flying in my ethernet dumps and haev identified the reason of problems being due to PRACK. ask cisco, why they have implemented PRACK in their SIP/PSTN GWs, not me. -- 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 Mar 20 05:53:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLHyn-0003Ft-42; Mon, 20 Mar 2006 05:51:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLHyk-0003Fj-S6 for sip@ietf.org; Mon, 20 Mar 2006 05:51:14 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLHyk-00055Q-2f for sip@ietf.org; Mon, 20 Mar 2006 05:51:14 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3CF455C5; Mon, 20 Mar 2006 11:51:13 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 11:51:12 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 11:51:11 +0100 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] The Problem with PRACK Date: Mon, 20 Mar 2006 11:51:10 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1B79@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZMCJfEVQQLpR6wQz+r/XqYsJjWIAAAGWHw From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 20 Mar 2006 10:51:11.0315 (UTC) FILETIME=[33734A30:01C64C0C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: sip@ietf.org, drage@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 am not Cisco, but I do have experience from PSTN GW implementation :) If we for the moment forget about preconditions and 3GPP, one reason a GW wants to use PRACK is to be able to send/receive an SDP answer in a reliable 18x, because they may require it in order to support "early media" etc (in which case one can't wait until 200 OK). Like it or not, but in all environments it simply isn't acceptable to "start listening for media from whoever/wherever/whatever once the INVITE has been sent". Another reason is SIP-I/SIP-t/SIP-whatver-you-call-it-when-you-encapsulate-ISUP-informatio n, where ISUP information is sent in a reliable 18x. No, Juha, it was NOT 3GPP who wanted ISUP encapsulation, so you don't have to blame it on them :) Another reason, maybe more theoretical at the moment, is that one wants to send non-SDP related requests before 200 OK, and in that case you need a reliable 18x to provide establish a route set. In any case, I don't think one can simply say "We don't need to care why PRACK causes problem - let's just get rid of it all". In that case we have to throw away the whole offer/answer mechanism (and a lot of other SIP features too), because I know it still causes interop problems - even without PRACK. One needs to identity WHY it causes problem. As I said earlier, from my experience PRACK has caused very little problem when it comes to provide reliable 18x responses. I believe the problems are related to offer/answer, and that is what was said in the initial mail of this whole thread. Most other people here seem to agree that the problems are related to offer/answer.=20 I haven't heard anyone else than Juha saying that PRACK is bad a such, eventhough there have been some discussions on how it could be improved (mandate Rseq value 1 for first response etc etc etc). Regards, Christer -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 20. maaliskuuta 2006 12:23 To: Erkki.Koivusalo@nokia.com Cc: sip@ietf.org; jh@tutpro.com; drage@lucent.com Subject: RE: [Sip] The Problem with PRACK Erkki.Koivusalo@nokia.com said: > - Your customers have bought lots of SIP phones with PRACK=20 > implementation > (with offer/answer if I understand you correctly) i don't know if with or w/o offer answer and i don't care. the thing that i know is that when new software has come out, phones that used to interoperate well with others, stopped doing so. > So do you have any idea, why those SIP phones used in non-3gpp=20 > environment have implemented PRACK which has caused so much problems ? > I do not believe they have added PRACK support. i have seen PRACK request flying in my ethernet dumps and haev identified the reason of problems being due to PRACK. ask cisco, why they have implemented PRACK in their SIP/PSTN GWs, not me. -- 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 Mar 20 06:27:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLIVa-0007qW-17; Mon, 20 Mar 2006 06:25:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLIVY-0007l8-Ul for sip@ietf.org; Mon, 20 Mar 2006 06:25:08 -0500 Received: from relay04s.clb.oleane.net ([213.56.31.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLIVX-0006VK-HH for sip@ietf.org; Mon, 20 Mar 2006 06:25:08 -0500 Received: from smtp11.clb.oleane.net (smtp11.clb.oleane.net [213.56.31.48]) by relay04s.clb.oleane.net with ESMTP id k2KBP6e1021835 for ; Mon, 20 Mar 2006 12:25:06 +0100 Received: from Pavillonquatre ([194.3.133.88]) by smtp11.clb.oleane.net with ESMTP id k2KAngpA019799 for ; Mon, 20 Mar 2006 11:50:21 +0100 Message-Id: <200603201050.k2KAngpA019799@smtp11.clb.oleane.net> From: "Chantal Ladouce" To: Date: Mon, 20 Mar 2006 11:49:33 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZMC/Wz28oAejEyTKujEtc+yMSUYQ== X-Spam-Score: 0.3 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Subject: [Sip] Wireless WiFi Convergence 2006 Conference & Exhibition - Paris - France X-BeenThere: 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="===============1873261959==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1873261959== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C64C14.5DCB0180" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C64C14.5DCB0180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 1st Edition of the Wireless WiFi Convergence 2006 Conference & Exhibition will stand in Paris next May 16 - 19, 2006 Only 2 weeks left to take advantage of our Early Bird Offer! Register before the 31st of March 2006 and benefit from a 10% discount on the registration fees. To register, please go to: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006registratio n.htm ------=_NextPart_000_0021_01C64C14.5DCB0180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 1st = Edition of the Wireless WiFi Convergence 2006 Conference & = Exhibition

=

will stand in Paris next May 16 - 19, 2006

=

 

=

Only 2 weeks left to take advantage of our = Early Bird Offer! =

Register before the 31st of March = 2006 and benefit from a 10% discount on the registration fees. 

 

To register, please go = to:

http://www.upperside.fr/wirelessconvergence2006/wwconv= ergence2006registration.htm

 

------=_NextPart_000_0021_01C64C14.5DCB0180-- --===============1873261959== 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 --===============1873261959==-- From sip-bounces@ietf.org Mon Mar 20 06:53:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLIul-0006UR-RH; Mon, 20 Mar 2006 06:51:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLIuk-0006UJ-3H for sip@ietf.org; Mon, 20 Mar 2006 06:51:10 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLIui-00075K-GV for sip@ietf.org; Mon, 20 Mar 2006 06:51:10 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2KBp7SK016891; Mon, 20 Mar 2006 13:51:07 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 13:51:06 +0200 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 13:51: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] The Problem with PRACK Date: Mon, 20 Mar 2006 13:51:03 +0200 Message-ID: <6D39732D264EEB43B83B6CC08FBEB4CA01D0D57A@esebe106.NOE.Nokia.com> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1B79@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZMCJfEVQQLpR6wQz+r/XqYsJjWIAAAGWHwAALCSZA= From: To: , , X-OriginalArrivalTime: 20 Mar 2006 11:51:06.0828 (UTC) FILETIME=[928B08C0:01C64C14] X-Spam-Score: 0.2 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: sip@ietf.org, drage@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 fully agree with Christer. I think the only thing that can be done at the moment is to follow the normal process in IETF (the one, that IETF also demanded from 3GPP, so people should know it), i.e. First investigate and write down requirements in an interndet-draft Second change the standards where necessary. So I propose a study/requirements I-D, in which people can=20 - state problems with PRACK - summarize existing implementations and possible impacts to them if PRACK gets changed - investigate impact on other standards bodies (3g2 3gpp tispan oma) when PRACK/precos get changed - propose and evaluate possible changes Based on the discussion I saw so far I do not see any way to start changing the RFCs right now. I would even doubt if the result of this investigation will be changing the existing RFCs.=20 Best regards Georg -- Georg Mayer - Nokia http://www.nokia.com/openness http://www.imsbook.com =20 >-----Original Message----- >From: ext Christer Holmberg (JO/LMF)=20 >[mailto:christer.holmberg@ericsson.com]=20 >Sent: 20 March, 2006 12:51 >To: jh@tutpro.com; Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: sip@ietf.org; drage@lucent.com >Subject: RE: [Sip] The Problem with PRACK > > >Hi, > >I am not Cisco, but I do have experience from PSTN GW implementation :) > >If we for the moment forget about preconditions and 3GPP, one=20 >reason a GW wants to use PRACK is to be able to send/receive=20 >an SDP answer in a reliable 18x, because they may require it=20 >in order to support "early media" etc (in which case one can't=20 >wait until 200 OK). Like it or not, but in all environments it=20 >simply isn't acceptable to "start listening for media from=20 >whoever/wherever/whatever once the INVITE has been sent". > >Another reason is >SIP-I/SIP-t/SIP-whatver-you-call-it-when-you-encapsulate-ISUP-i >nformatio >n, where ISUP information is sent in a reliable 18x. No, Juha,=20 >it was NOT 3GPP who wanted ISUP encapsulation, so you don't=20 >have to blame it on them :) > >Another reason, maybe more theoretical at the moment, is that=20 >one wants to send non-SDP related requests before 200 OK, and=20 >in that case you need a reliable 18x to provide establish a route set. > >In any case, I don't think one can simply say "We don't need=20 >to care why PRACK causes problem - let's just get rid of it=20 >all". In that case we have to throw away the whole=20 >offer/answer mechanism (and a lot of other SIP features too),=20 >because I know it still causes interop problems - even without PRACK. > >One needs to identity WHY it causes problem. As I said=20 >earlier, from my experience PRACK has caused very little=20 >problem when it comes to provide reliable 18x responses. I=20 >believe the problems are related to offer/answer, and that is=20 >what was said in the initial mail of this whole thread. Most=20 >other people here seem to agree that the problems are related=20 >to offer/answer.=20 > >I haven't heard anyone else than Juha saying that PRACK is bad=20 >a such, eventhough there have been some discussions on how it=20 >could be improved (mandate Rseq value 1 for first response etc=20 >etc etc). > >Regards, > >Christer > > > >-----Original Message----- >From: Juha Heinanen [mailto:jh@tutpro.com] >Sent: 20. maaliskuuta 2006 12:23 >To: Erkki.Koivusalo@nokia.com >Cc: sip@ietf.org; jh@tutpro.com; drage@lucent.com >Subject: RE: [Sip] The Problem with PRACK > >Erkki.Koivusalo@nokia.com said: > >> - Your customers have bought lots of SIP phones with PRACK=20 >> implementation >> (with offer/answer if I understand you correctly) > >i don't know if with or w/o offer answer and i don't care. =20 >the thing that i know is that when new software has come out,=20 >phones that used to interoperate well with others, stopped doing so. > >> So do you have any idea, why those SIP phones used in non-3gpp=20 >> environment have implemented PRACK which has caused so much=20 >problems ? > >> I do not believe they have added PRACK support. > >i have seen PRACK request flying in my ethernet dumps and haev=20 >identified the reason of problems being due to PRACK. ask=20 >cisco, why they have implemented PRACK in their SIP/PSTN GWs, not me. > >-- juha > > >_______________________________________________ >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 Mon Mar 20 08:41:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKbI-0004NY-9u; Mon, 20 Mar 2006 08:39:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKbH-0004NT-0C for sip@ietf.org; Mon, 20 Mar 2006 08:39:11 -0500 Received: from mail.gt.ca ([216.18.99.22]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLKbF-0002Sm-Il for sip@ietf.org; Mon, 20 Mar 2006 08:39:10 -0500 Received: from unknown(172.22.198.31) by mail.gt.ca via csmap id 2ad14508_b818_11da_95a1_00304811dcb9_7052; Mon, 20 Mar 2006 05:48:09 -0800 (PST) Received: by svbcexgr01.gt.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Mar 2006 05:39:37 -0800 Message-ID: From: Rehan Khan To: "'sip@ietf.org'" Date: Mon, 20 Mar 2006 05:39:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] 3-way Handshake X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Other than Invite, is there any other method that involves a 3 way handshake Thanks Rehan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 20 09:10:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLL3N-0004UE-7f; Mon, 20 Mar 2006 09:08:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLL3L-0004R5-M0 for sip@ietf.org; Mon, 20 Mar 2006 09:08:11 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLL3K-0003DN-DM for sip@ietf.org; Mon, 20 Mar 2006 09:08:11 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Mar 2006 06:08:09 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,111,1141632000"; d="scan'208"; a="23988382:sNHT23624908" 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 k2KE89VU022676; Mon, 20 Mar 2006 09:08:09 -0500 (EST) 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.211); Mon, 20 Mar 2006 09:08:09 -0500 Received: from [130.129.128.208] ([10.86.242.24]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 09:08:09 -0500 Message-ID: <441EB74A.40105@cisco.com> Date: Mon, 20 Mar 2006 09:08:10 -0500 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: Rehan Khan Subject: Re: [Sip] 3-way Handshake References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 14:08:09.0140 (UTC) FILETIME=[B76C4740:01C64C27] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 No. For other methods that need a similar kind of mechanism, two non-INVITE requests (each of which is two-way) are used. For example, see SUBSCRIBE/NOTIFY. -Jonathan R. Rehan Khan wrote: > HI, > > Other than Invite, is there any other method that involves a 3 way handshake > > > Thanks > > Rehan > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Mon Mar 20 09:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLNI-0008IY-U1; Mon, 20 Mar 2006 09:28:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLNH-0008H2-5u; Mon, 20 Mar 2006 09:28:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLNG-0003tB-V2; Mon, 20 Mar 2006 09:28:47 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLLNG-0004gr-4g; Mon, 20 Mar 2006 14:28:46 +0000 To: sip@ietf.org, sipping@ietf.org Date: Mon, 20 Mar 2006 06:28:46 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: fluffy@cisco.com, jon.peterson@neustar.biz, mankin@psg.com Subject: [Sip] Regime Change X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Message-Id: Hi, SIP and SIPPING folks, As you know well, the SIP and SIPPING Working Groups have moved to the RAI Area this IETF. The new Area Directors, Cullen and Jon, have started their work now, though the tracker will not start showing this until Friday. Since SIP and SIPPING formed, the work has been intense, with close to forty documents completed between the groups just since 2005. And the pace has been like this for years. This is a very good time for the Chairs to get some rest and reinforcements. Rohan joins me in choosing to return to the technical ranks. He deserves great thanks for co-chairing both groups with humor and skill. Dean is moving to handling just one co-chairship, SIP, because he has found his energy for railing and fuming was getting low! And two new folks have been willing to come in as reinforcements for Dean and Gonzalo. So the new Chairs are: SIP - Dean Willis and Keith Drage SIPPING - Gonzalo Camarillo and Mary Barnes Thanks, everyone, and Good luck, everyone. It's been fun. Allison _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 20 09:39:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLVh-0004fv-0t; Mon, 20 Mar 2006 09:37:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLVf-0004fM-Sq for sip@ietf.org; Mon, 20 Mar 2006 09:37:27 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLVe-0004D9-7j for sip@ietf.org; Mon, 20 Mar 2006 09:37:27 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2006 06:37:26 -0800 X-IronPort-AV: i="4.03,111,1141632000"; d="scan'208"; a="1786411293:sNHT48244638" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2KEbOYg004092; Mon, 20 Mar 2006 06:37:24 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 09:37:19 -0500 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] The Problem with PRACK Date: Mon, 20 Mar 2006 09:37:18 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3013D7D20@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZMCJfEVQQLpR6wQz+r/XqYsJjWIAAAGWHwAALCSZAABa2FIA== From: "Michael Hammer \(mhammer\)" To: , , , X-OriginalArrivalTime: 20 Mar 2006 14:37:19.0058 (UTC) FILETIME=[CA749320:01C64C2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: sip@ietf.org, drage@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 Ummm... I thought some one else indicated that the problem is with Offer/Answer, not PRACK. I also thought the principle behind Offer/Answer was that the SDP negotiation was independent of the signaling message it was carried in, *so long* as those messages were reliable. However, it was pointed out to me that you can't put an Offer in this or that message, indicating to me that perhaps the Offer/Answer was complicated by the permutations of messages where it can or can not be carried. On some PSTN gateways this may be complicated because the MGC generally handles the SIP termination, while the SDP is terminated by the MG, once it has been passed from SIP to MGCP or H.248 and vice versa. Anyway, I haven't seen the 50+ state diagram from Vancouver either, but it would be good to have that distributed on the mail list. I must have missed that one if it was. Mike > -----Original Message----- > From: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com]=20 > Sent: Monday, March 20, 2006 6:51 AM > To: christer.holmberg@ericsson.com; jh@tutpro.com;=20 > Erkki.Koivusalo@nokia.com > Cc: sip@ietf.org; drage@lucent.com > Subject: RE: [Sip] The Problem with PRACK >=20 > Hi, >=20 > I fully agree with Christer. I think the only thing that can=20 > be done at the moment is to follow the normal process in IETF=20 > (the one, that IETF also demanded from 3GPP, so people should=20 > know it), i.e. >=20 > First investigate and write down requirements in an=20 > interndet-draft Second change the standards where necessary. >=20 > So I propose a study/requirements I-D, in which people can=20 > - state problems with PRACK > - summarize existing implementations and possible=20 > impacts to them if PRACK gets changed > - investigate impact on other standards bodies (3g2 3gpp tispan > oma) when PRACK/precos get changed > - propose and evaluate possible changes >=20 > Based on the discussion I saw so far I do not see any way to=20 > start changing the RFCs right now. I would even doubt if the=20 > result of this investigation will be changing the existing RFCs.=20 >=20 > Best regards > Georg >=20 > -- > Georg Mayer - Nokia > http://www.nokia.com/openness > http://www.imsbook.com > =20 >=20 > >-----Original Message----- > >From: ext Christer Holmberg (JO/LMF) > >[mailto:christer.holmberg@ericsson.com] > >Sent: 20 March, 2006 12:51 > >To: jh@tutpro.com; Koivusalo Erkki (Nokia-TP-MSW/Helsinki) > >Cc: sip@ietf.org; drage@lucent.com > >Subject: RE: [Sip] The Problem with PRACK > > > > > >Hi, > > > >I am not Cisco, but I do have experience from PSTN GW=20 > implementation :) > > > >If we for the moment forget about preconditions and 3GPP, one=20 > >reason a GW wants to use PRACK is to be able to send/receive=20 > >an SDP answer in a reliable 18x, because they may require it=20 > >in order to support "early media" etc (in which case one can't=20 > >wait until 200 OK). Like it or not, but in all environments it=20 > >simply isn't acceptable to "start listening for media from=20 > >whoever/wherever/whatever once the INVITE has been sent". > > > >Another reason is > >SIP-I/SIP-t/SIP-whatver-you-call-it-when-you-encapsulate-ISUP-i > >nformatio > >n, where ISUP information is sent in a reliable 18x. No, Juha,=20 > >it was NOT 3GPP who wanted ISUP encapsulation, so you don't=20 > >have to blame it on them :) > > > >Another reason, maybe more theoretical at the moment, is that=20 > >one wants to send non-SDP related requests before 200 OK, and=20 > >in that case you need a reliable 18x to provide establish a=20 > route set. > > > >In any case, I don't think one can simply say "We don't need=20 > >to care why PRACK causes problem - let's just get rid of it=20 > >all". In that case we have to throw away the whole=20 > >offer/answer mechanism (and a lot of other SIP features too),=20 > >because I know it still causes interop problems - even without PRACK. > > > >One needs to identity WHY it causes problem. As I said=20 > >earlier, from my experience PRACK has caused very little=20 > >problem when it comes to provide reliable 18x responses. I=20 > >believe the problems are related to offer/answer, and that is=20 > >what was said in the initial mail of this whole thread. Most=20 > >other people here seem to agree that the problems are related=20 > >to offer/answer.=20 > > > >I haven't heard anyone else than Juha saying that PRACK is bad=20 > >a such, eventhough there have been some discussions on how it=20 > >could be improved (mandate Rseq value 1 for first response etc=20 > >etc etc). > > > >Regards, > > > >Christer > > > > > > > >-----Original Message----- > >From: Juha Heinanen [mailto:jh@tutpro.com] > >Sent: 20. maaliskuuta 2006 12:23 > >To: Erkki.Koivusalo@nokia.com > >Cc: sip@ietf.org; jh@tutpro.com; drage@lucent.com > >Subject: RE: [Sip] The Problem with PRACK > > > >Erkki.Koivusalo@nokia.com said: > > > >> - Your customers have bought lots of SIP phones with PRACK=20 > >> implementation > >> (with offer/answer if I understand you correctly) > > > >i don't know if with or w/o offer answer and i don't care. =20 > >the thing that i know is that when new software has come out,=20 > >phones that used to interoperate well with others, stopped doing so. > > > >> So do you have any idea, why those SIP phones used in non-3gpp=20 > >> environment have implemented PRACK which has caused so much=20 > >problems ? > > > >> I do not believe they have added PRACK support. > > > >i have seen PRACK request flying in my ethernet dumps and haev=20 > >identified the reason of problems being due to PRACK. ask=20 > >cisco, why they have implemented PRACK in their SIP/PSTN GWs, not me. > > > >-- juha > > > > > >_______________________________________________ > >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 >=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 Mar 20 09:55:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLlh-0006pg-E4; Mon, 20 Mar 2006 09:54:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLlf-0006nJ-Sd for sip@ietf.org; Mon, 20 Mar 2006 09:53:59 -0500 Received: from web52812.mail.yahoo.com ([206.190.49.1]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLLle-0004w9-Gc for sip@ietf.org; Mon, 20 Mar 2006 09:53:59 -0500 Received: (qmail 67059 invoked by uid 60001); 20 Mar 2006 14:53:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VuVBW29D2Txj054YcuWtGmVBIr+rBoVlANRwrRzMaixIZ71EisAWwb7s7rOj2mgDVD1zyfl1jtq1hK4bLASK0+BeAx7RXlSkBy3vV5Rga4131HLgG6dfqFXoreHSE72mHC6/B+13b1RM88rHrSU6HazrapJ3Ex2jKnDxKmcSN3U= ; Message-ID: <20060320145358.67057.qmail@web52812.mail.yahoo.com> Received: from [47.165.147.102] by web52812.mail.yahoo.com via HTTP; Mon, 20 Mar 2006 06:53:58 PST Date: Mon, 20 Mar 2006 06:53:58 -0800 (PST) From: Fatih "Eyüp" NAR Subject: Re: [Sip] 3-way Handshake To: Jonathan Rosenberg , Rehan Khan In-Reply-To: <441EB74A.40105@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 or PRACK can be used for provisional response verification which will (kind-of) give 3(~5way) way handshake feel :-) . sometimes I think we should have prack for final responses too ,instead of waiting transaction-timeout renewal of message. regards fatih e. --- Jonathan Rosenberg wrote: > No. For other methods that need a similar kind of > mechanism, two > non-INVITE requests (each of which is two-way) are > used. For example, > see SUBSCRIBE/NOTIFY. > > -Jonathan R. > > Rehan Khan wrote: > > > HI, > > > > Other than Invite, is there any other method that > involves a 3 way handshake > > > > > > Thanks > > > > Rehan > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 20 10:41:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMUD-0008Ag-Np; Mon, 20 Mar 2006 10:40:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMUD-0008Ab-21 for sip@ietf.org; Mon, 20 Mar 2006 10:40:01 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMUA-0006wJ-VY for sip@ietf.org; Mon, 20 Mar 2006 10:40:01 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2KFdfD0031771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Mar 2006 09:39:41 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441ECCBD.1080402@nostrum.com> Date: Mon, 20 Mar 2006 09:39:41 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] The Problem with PRACK References: <072C5B76F7CEAB488172C6F64B30B5E3013D7D20@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3013D7D20@xmb-rtp-20b.amer.cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: ecd31d0ad136cbe3c6379fa18e645208 Cc: sip@ietf.org, jh@tutpro.com, christer.holmberg@ericsson.com, drage@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 Michael Hammer (mhammer) wrote: >Anyway, I haven't seen the 50+ state diagram from Vancouver either, but >it would be good to have that distributed on the mail list. I must have >missed that one if it was. Because the graphic doesn't work well on a mailing list, I've put it here in text format. If you want the visual impact of the graph that Rohan put up at IETF64, grab the PDF file at http://scm.sipfoundry.org/viewsvn/*checkout*/resiprocate/main/resip/dum/doc/dum-fsms1.pdf This comes from the Dialog Usage Manager in the resiprocate stack; the transition is denoted as "oldstate->newstate"; the trigger and subsequent actions are indicated following that line. UAC_Start -> UAC_Early trigger = on1xxI action = app::onNewSession action = timer::StaleCall action = app::onProvisional UAC_Start -> UAC_Early trigger = on1xxI-early action = app::onNewSession action = timer::StaleCall action = app::onProvisional action = app::onEarlyMedia UAC_Start -> UAC_EarlyWithOffer trigger = on1xxI-offer action = app::onNewSession action = timer::StaleCall action = app::onProvisional action = app::onOffer UAC_Start -> UAC_EarlyWithAnswer trigger = on1xxI-answer action = app::onNewSession action = timer::StaleCall action = app::onProvisional action = app::onAnswer action = send::PRACK UAC_Start -> UAC_Answered trigger = on2xxI-offer action = app::onNewSession action = app::onOffer action = app::onConnected UAC_Start -> Connected trigger = on2xxI-answer action = send::ACK action = app::onNewSession action = app::onAnswer action = app::onConnected UAC_Start -> Terminated trigger = on2xxI action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_Start -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_Start -> Terminated trigger = onRedirect action = app::onRedirected UAC_Start -> Assert trigger = dum::cancel action = assert UAC_Early -> UAC_Early trigger = on1xxI action = timer::StaleCall action = app::onProvisional action = send::PRACK UAC_Early -> UAC_Early trigger = on1xxI-early action = timer::StaleCall action = app::onProvisional action = app::onEarlyMedia UAC_Early -> UAC_EarlyWithOffer trigger = on1xxI-offer action = timer::StaleCall action = app::onProvisional action = app::onOffer UAC_Early -> UAC_EarlyWithAnswer trigger = on1xxI-answer action = timer::StaleCall action = app::onProvisional action = app::onAnswer action = send::PRACK UAC_Early -> UAC_Answered trigger = on2xxI-offer action = app::onOffer action = app::onConnected UAC_Early -> Connected trigger = on2xxI-answer action = send::ACK action = app::onAnswer action = app::onConnected UAC_Early -> Terminated trigger = on2xxI action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_Early -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_Early -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_Early -> Terminated trigger = onRedirect action = app::onRedirected UAC_Early -> Assert trigger = dum::provideAnswer action = assert UAC_Early -> Assert trigger = dum::provideOffer action = assert UAC_Early -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_EarlyWithOffer -> UAC_EarlyWithOffer trigger = on1xxI action = timer::StaleCall action = app::onProvisional action = send::PRACK UAC_EarlyWithOffer -> UAC_SentAnswer trigger = dum::provideAnswer action = send::PRACK-answer UAC_EarlyWithOffer -> Terminated trigger = on2xxI trigger = on2xxI-answer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_EarlyWithOffer -> Terminated trigger = onRedirect action = app::onRedirected UAC_EarlyWithOffer -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_EarlyWithOffer -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_EarlyWithOffer -> Assert trigger = dum::provideOffer action = assert UAC_EarlyWithOffer -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_EarlyWithAnswer -> UAC_EarlyWithAnswer trigger = on1xxI action = timer::StaleCall action = app::onProvisional action = send::PRACK UAC_EarlyWithAnswer -> Connected trigger = on2xxI action = send::ACK action = app::onConnected UAC_EarlyWithAnswer -> Terminated trigger = on2xxI-offer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_EarlyWithAnswer -> UAC_ReceivedUpdateEarly trigger = onUpdate action = app::onOffer UAC_EarlyWithAnswer -> UAC_SentUpdateEarly trigger = dum::provideOffer action = send::UPDATE UAC_EarlyWithAnswer -> Terminated trigger = onRedirect action = app::onRedirected UAC_EarlyWithAnswer -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_EarlyWithAnswer -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_EarlyWithAnswer -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_EarlyWithAnswer -> Assert trigger = dum::provideAnswer action = assert UAC_SentUpdateEarly -> UAC_EarlyWithAnswer trigger = on2xxU action = app::onAnswer UAC_SentUpdateEarly -> UAC_EarlyWithAnswer trigger = onUpdate action = send::491 UAC_SentUpdateEarly -> UAC_EarlyWithAnswer trigger = on491U action = app::onOfferRejected UAC_SentUpdateEarly -> UAC_SentUpdateConnected trigger = on2xxI action = send::ACK UAC_SentUpdateEarly -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_SentUpdateEarly -> Assert trigger = dum::provideAnswer action = assert UAC_SentUpdateEarly -> Assert trigger = dum::provideOffer action = assert UAC_SentUpdateEarly -> Terminated trigger = onRedirect action = app::onRedirected UAC_SentUpdateEarly -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_SentUpdateEarly -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_SentUpdateConnected -> Connected trigger = on2xxU action = app::onAnswer UAC_SentUpdateConnected -> Connected trigger = onUpdateFailure action = app::onOfferRejected UAC_SentUpdateConnected -> Connected trigger = on491U action = glare UAC_SentUpdateConnected -> Assert trigger = dum::cancel action = assert UAC_SentUpdateConnected -> Assert trigger = dum::provideAnswer action = assert UAC_SentUpdateConnected -> Assert trigger = dum::provideOffer action = assert UAC_SentUpdateConnected -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_ReceivedUpdateEarly -> Terminated trigger = onRedirect action = app::onRedirected UAC_ReceivedUpdateEarly -> UAC_EarlyWithAnswer trigger = dum::provideAnswer action = send::200U-answer UAC_ReceivedUpdateEarly -> UAC_EarlyWithAnswer trigger = dum::reject action = send::488U UAC_ReceivedUpdateEarly -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_ReceivedUpdateEarly -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_ReceivedUpdateEarly -> Assert trigger = dum::provideAnswer action = assert UAC_ReceivedUpdateEarly -> Assert trigger = dum::provideOffer action = assert UAC_Answered -> Connected trigger = dum::provideAnswer action = send::ACK-answer action = app::onConnected UAC_Answered -> Assert trigger = dum::provideOffer action = assert UAC_Answered -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_Answered -> Assert trigger = dum::cancel action = assert UAC_SentAnswer -> UAC_EarlyWithAnswer trigger = on2xxP UAC_SentAnswer -> Connected trigger = on2xxI action = send::ACK action = app::onConnected UAC_SentAnswer -> Terminated trigger = on1xxI-offer trigger = on1xxI-answer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_SentAnswer -> Terminated trigger = on2xxI-offer trigger = on2xxI-answer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_SentAnswer -> UAC_EarlyWithAnswer trigger = on1xxI action = timer::StaleCall action = app::onProvisional action = send::PRACK UAC_SentAnswer -> Terminated trigger = onRedirect action = app::onRedirected UAC_SentAnswer -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_SentAnswer -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_SentAnswer -> UAC_QueuedUpdate trigger = dum::provideOffer action = store::offer UAC_SentAnswer -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_SentAnswer -> Assert trigger = dum::provideAnswer action = assert UAC_QueuedUpdate -> UAC_SentUpdateEarly trigger = on2xxP action = send::UPDATE-offer UAC_QueuedUpdate -> SentUpdate trigger = on2xxI action = send::ACK action = app::onConnected action = send::UPDATE-offer UAC_QueuedUpdate -> Terminated trigger = on1xxI-offer trigger = on1xxI-answer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_QueuedUpdate -> Terminated trigger = on2xxI-offer trigger = on2xxI-answer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_QueuedUpdate -> UAC_QueuedUpdate trigger = on1xxI action = timer::StaleCall action = app::onProvisional action = send::PRACK UAC_QueuedUpdate -> Terminated trigger = onRedirect action = app::onRedirected UAC_QueuedUpdate -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_QueuedUpdate -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_QueuedUpdate -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_QueuedUpdate -> Assert trigger = dum::provideAnswer action = assert UAC_QueuedUpdate -> Assert trigger = dum::provideOffer action = assert UAC_Cancelled -> Terminated trigger = onTimerCancel action = send::487 action = app::onTerminated UAC_Cancelled -> Terminated trigger = on2xxI trigger = on2xxI-offer trigger = on2xxI-answer action = send::ACK action = send::BYE action = app::onTerminated UAC_Cancelled -> Terminated trigger = onRedirect action = app::onRedirected UAC_Cancelled -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_Cancelled -> UAC_Cancelled trigger = dum::cancel UAC_Cancelled -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated Connected -> SentUpdate trigger = dum::provideOffer action = send::UPDATE Connected -> SentReinvite trigger = dum::provideOffer action = send::INVITE Connected -> SentReinviteNoOffer trigger = dum::requestOffer action = send::INVITE Connected -> ReceivedUpdate trigger = onUpdate action = app::onOffer Connected -> ReceivedReinvite trigger = onInvite-offer action = app::onOffer Connected -> ReceivedReinviteNoOffer trigger = onInvite action = app::onOfferRequired Connected -> Connected trigger = on2xxP Connected -> Connected trigger = on2xxI action = resend::ACK Connected -> Connected trigger = onTimer2xx action = resend::2xx Connected -> Connected trigger = onCancel action = send::200C Connected -> Terminated trigger = dum::end action = send::BYE Connected -> Terminated trigger = onBye action = send::200B action = app::onTerminated SentUpdate -> Connected trigger = on2xxU action = app::onAnswer SentUpdate -> Connected trigger = onUpdateFailure action = app::onOfferRejected SentUpdate -> SentUpdate trigger = onUpdate trigger = onInvite action = send::491 SentUpdate -> SentUpdateGlare trigger = on491U action = timer::491 SentUpdate -> Terminated trigger = onGeneralFailure action = app::onTerminated action = send::BYE SentUpdate -> Terminated trigger = dum::end action = send::BYE SentUpdateGlare -> SentUpdate trigger = onTimer491 action = resend::UPDATE SentUpdateGlare -> ReceivedUpdate trigger = onUpdate action = app::onOfferRejected action = app::onOffer SentUpdateGlare -> ReceivedReinvite trigger = onInvite-offer action = app::onOfferRejected action = app::onOffer SentUpdateGlare -> Terminated trigger = dum::end action = send::BYE SentReinvite -> Connected trigger = on2xxI-answer action = app::onAnswer action = send::ACK SentReinvite -> Connected trigger = on2xxI action = app::onIllegalNegotiation action = send::ACK SentReinvite -> Connected trigger = onInviteFailure action = app::onOfferRejected SentReinvite -> SentReinvite trigger = onInvite trigger = onUpdate action = send::491 SentReinvite -> SentReinviteGlare trigger = on491I action = timer::491 SentReinvite -> WaitingToTerminate trigger = dum::end SentReinviteGlare -> SentReinvite trigger = onTimer491 action = resend::INVITE SentReinviteGlare -> ReceivedUpdate trigger = onUpdate action = app::onOfferRejected action = app::onOffer SentReinviteGlare -> ReceivedReinvite trigger = onInvite-offer action = app::onOfferRejected action = app::onOffer SentReinviteGlare -> ReceivedReinviteNoOffer trigger = onInvite action = app::onOfferRejected action = app::onOfferRequired SentReinviteGlare -> Terminated trigger = dum::end action = send::BYE SentReinviteNoOffer -> SentReinviteAnswered trigger = on2xxI-offer action = app::onOffer SentReinviteNoOffer -> Connected trigger = on2xxI action = app::onIllegalNegotiation action = send::ACK SentReinviteNoOffer -> Connected trigger = onInviteFailure action = app::onOfferRequestRejected SentReinviteNoOffer -> SentReinviteNoOffer trigger = onInvite trigger = onUpdate action = send::491 SentReinviteNoOffer -> SentReinviteNoOfferGlare trigger = on491I action = timer::491 SentReinviteNoOffer -> WaitingToTerminate trigger = dum::end SentReinviteAnswered -> Connected trigger = dum::provideAnswer action = send::ACK-answer SentReinviteAnswered -> Terminated trigger = dum::end action = app::onTerminated action = send::BYE SentReinviteNoOfferGlare -> SentReinviteNoOffer trigger = onTimer491 action = resend::INVITE SentReinviteNoOfferGlare -> ReceivedUpdate trigger = onUpdate action = app::onOfferRequestRejected action = app::onOffer SentReinviteNoOfferGlare -> ReceivedReinvite trigger = onInvite action = app::onOfferRequestRejected action = app::onOffer SentReinviteNoOfferGlare -> ReceivedReinviteNoOffer trigger = onInvite action = app::onOfferRequestRejected action = app::onOfferRequired SentReinviteNoOfferGlare -> Terminated trigger = dum::end action = send::BYE ReceivedUpdate -> Connected trigger = dum::provideAnswer action = send::200U ReceivedUpdate -> Connected trigger = dum::reject action = send::488U ReceivedUpdate -> Terminated trigger = dum::end action = send::488U action = send::BYE ReceivedUpdate -> ReceivedUpdate trigger = onInvite trigger = onUpdate action = send::500 ReceivedReinvite -> Answered trigger = dum::provideAnswer action = send::200I action = timer::200I action = timer::NoAck ReceivedReinvite -> Connected trigger = dum::reject action = send::488U ReceivedReinvite -> Terminated trigger = dum::end action = send::488I action = send::BYE ReceivedReinvite -> ReceivedReinvite trigger = onInvite trigger = onUpdate action = send::500 Answered -> Answered trigger = onTimer2xx action = resend::2xx Answered -> WaitingToOffer trigger = dum::provideOffer action = store::offer Answered -> WaitingToRequestOffer trigger = dum::requestOffer Answered -> Connected trigger = onAck action = timer::NoAck action = app::onAckNotReceived Answered -> WaitingToHangup trigger = dum::end WaitingToOffer -> WaitingToOffer trigger = onTimer2xx action = resend::2xx WaitingToOffer -> SentUpdate trigger = onAck action = send::UPDATE-offer WaitingToOffer -> SentReinvite trigger = onAck action = send::INVITE-offer WaitingToOffer -> SentUpdate trigger = onTimerNoAck action = app::onOfferRejected action = send::UPDATE-offer WaitingToOffer -> SentReinvite trigger = onTimerNoAck action = app::onOfferRejected action = send::INVITE-offer WaitingToOffer -> WaitingToHangup trigger = dum::end WaitingToRequestOffer -> WaitingToRequestOffer trigger = onTimer2xx action = resend::2xx WaitingToRequestOffer -> SentUpdate trigger = onAck action = send::UPDATE-offer WaitingToRequestOffer -> SentReinvite trigger = onAck action = send::INVITE-offer WaitingToRequestOffer -> SentReinviteNoOffer trigger = onAck action = send::INVITE WaitingToRequestOffer -> SentUpdate trigger = onTimerNoAck action = app::onOfferRejected action = send::UPDATE-offer WaitingToRequestOffer -> SentReinvite trigger = onTimerNoAck action = app::onOfferRejected action = send::INVITE-offer WaitingToRequestOffer -> SentReinviteNoOffer trigger = onTimerNoAck action = app::onOfferRejected action = send::INVITE WaitingToRequestOffer -> WaitingToHangup trigger = dum::end ReceivedReinviteNoOffer -> ReceivedReinviteSentOffer trigger = dum::provideOffer action = send::200-offer action = timer::200I action = timer::NoAck ReceivedReinviteNoOffer -> Connected trigger = dum::reject action = send::488I ReceivedReinviteNoOffer -> Terminated trigger = dum::end action = send::488I action = send::BYE ReceivedReinviteNoOffer -> ReceivedReinviteNoOffer trigger = onInvite trigger = onUpdate action = send::500 ReceivedReinviteSentOffer -> Connected trigger = onAck-answer action = app::onAnswer ReceivedReinviteSentOffer -> Connected trigger = onAck action = app::onOfferRejected ReceivedReinviteSentOffer -> ReceivedReinviteSentOffer trigger = onTimer2xx action = resend::2xxI ReceivedReinviteSentOffer -> Connected trigger = onTimerNoAck action = app::onOfferRejected ReceivedReinviteSentOffer -> WaitingToHangup trigger = dum::end WaitingToTerminate -> Terminated trigger = on2xxI action = send::ACK action = send::BYE WaitingToTerminate -> Terminated trigger = onInviteFailure action = send::BYE WaitingToHangup -> Terminated trigger = onAck action = send::BYE WaitingToHangup -> Terminated trigger = onTimerNoAck action = send::BYE Terminated -> Terminated trigger = onResponse action = dum::destroy Terminated -> Terminated trigger = onRequest action = send::481 action = dum::destroy UAS_Start -> UAS_Offer trigger = onInvite-offer action = app::onNewSession action = app::onOffer UAS_Offer -> UAS_OfferProvidedAnswer trigger = dum::provideAnswer action = store::answer UAS_Offer -> UAS_EarlyOffer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_Offer -> Assert trigger = dum::accept action = assert UAS_Offer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_Offer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_Offer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_Offer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I UAS_Offer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I UAS_OfferProvidedAnswer -> UAS_Accepted trigger = dum::accept action = send::2xx-answer action = timer::2xx action = timer::NoAck action = app::onConnected UAS_OfferProvidedAnswer -> UAS_EarlyProvidedAnswer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_OfferProvidedAnswer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_OfferProvidedAnswer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_OfferProvidedAnswer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_OfferProvidedAnswer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I UAS_OfferProvidedAnswer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I UAS_Accepted -> Connected trigger = onAck UAS_Accepted -> UAS_Accepted trigger = onCancel action = send::200C UAS_Accepted -> UAS_Accepted trigger = onTimer2xx action = resend::2xxI UAS_Accepted -> Terminated trigger = onAck-answer action = send::BYE UAS_Accepted -> Terminated trigger = onTimerNoAck action = app::onAckNotReceived action = app::onTerminated action = send::BYE UAS_Accepted -> Terminated trigger = onBye action = app::onTerminated action = send::200B UAS_Accepted -> UAS_WaitingToHangup trigger = dum::end UAS_Accepted -> UAS_WaitingToOffer trigger = dum::provideOffer action = store::offer UAS_WaitingToOffer -> UAS_SentUpdate trigger = onAck action = send::UPDATE-offer UAS_WaitingToOffer -> SentReinvite trigger = onAck action = send::INVITE-offer UAS_WaitingToOffer -> UAS_WaitingToOffer trigger = onCancel action = send::200C UAS_WaitingToOffer -> UAS_WaitingToOffer trigger = onTimer2xx action = resend::2xxI UAS_WaitingToOffer -> Terminated trigger = onAck-answer action = send::BYE UAS_WaitingToOffer -> Terminated trigger = onTimerNoAck action = app::onAckNotReceived action = app::onTerminated action = send::BYE UAS_WaitingToOffer -> Terminated trigger = onBye action = app::onTerminated action = send::200B UAS_WaitingToOffer -> UAS_WaitingToHangup trigger = dum::end UAS_EarlyOffer -> UAS_EarlyOffer trigger = onTimer1xx action = resend::1xx UAS_EarlyOffer -> UAS_EarlyOffer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_EarlyOffer -> UAS_EarlyProvidedAnswer trigger = dum::provideAnswer action = store::answer UAS_EarlyOffer -> Assert trigger = dum::accept action = assert UAS_EarlyOffer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyOffer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyOffer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_EarlyOffer -> Terminated trigger = onCancel action = send::200C action = send::487I UAS_EarlyOffer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I UAS_EarlyProvidedAnswer -> UAS_EarlyProvidedAnswer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_EarlyProvidedAnswer -> UAS_Accepted trigger = dum::accept action = send::2xx-answer action = timer::2xx action = timer::NoAck action = app::onConnected UAS_EarlyProvidedAnswer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedAnswer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedAnswer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedAnswer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I UAS_EarlyProvidedAnswer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I UAS_Start -> UAS_NoOffer trigger = onInvite action = app::onNewSession action = app::onOfferRequired UAS_NoOffer -> UAS_ProvidedOffer trigger = dum::provideOffer action = store::offer UAS_NoOffer -> UAS_EarlyNoOffer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_NoOffer -> Assert trigger = dum::accept action = assert UAS_NoOffer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_NoOffer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_NoOffer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_NoOffer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I action = dum::destroy UAS_NoOffer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I action = dum::destroy UAS_ProvidedOffer -> UAS_EarlyProvidedOffer trigger = dum::provisional action = send::1xx-early action = timer::1xx UAS_ProvidedOffer -> UAS_AcceptedWaitingAnswer trigger = dum::accept action = send::2xxI-offer action = timer::2xx action = timer::NoAck UAS_ProvidedOffer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_ProvidedOffer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_ProvidedOffer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_ProvidedOffer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I action = dum::destroy UAS_ProvidedOffer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I action = dum::destroy UAS_EarlyNoOffer -> UAS_EarlyNoOffer trigger = onTimer1xx action = resend::1xx UAS_EarlyNoOffer -> UAS_EarlyNoOffer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_EarlyNoOffer -> UAS_EarlyProvidedOffer trigger = dum::provideOffer action = store::offer UAS_EarlyNoOffer -> Assert trigger = dum::accept action = assert UAS_EarlyNoOffer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyNoOffer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyNoOffer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_EarlyNoOffer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I action = dum::destroy UAS_EarlyNoOffer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I action = dum::destroy UAS_EarlyProvidedOffer -> UAS_EarlyProvidedOffer trigger = dum::provisional action = send::1xx-early action = timer::1xx UAS_EarlyProvidedOffer -> UAS_AcceptedWaitingAnswer trigger = dum::accept action = send::2xxI-offer action = timer::2xx action = timer::NoAck UAS_EarlyProvidedOffer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedOffer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedOffer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedOffer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I action = dum::destroy UAS_EarlyProvidedOffer -> Terminated trigger = onTerminated trigger = onBye action = send::200B action = send::487I action = dum::destroy UAS_AcceptedWaitingAnswer -> Connected trigger = onAck-answer action = app::onAnswer UAS_AcceptedWaitingAnswer -> UAS_AcceptedWaitingAnswer trigger = onCancel action = send::200C UAS_AcceptedWaitingAnswer -> UAS_AcceptedWaitingAnswer trigger = onPrack action = send::2xxP action = send::2xxI-offer UAS_AcceptedWaitingAnswer -> Terminated trigger = onTimer2xx action = resend::2xxI UAS_AcceptedWaitingAnswer -> Terminated trigger = onTimerNoAck action = send::BYE UAS_AcceptedWaitingAnswer -> UAS_WaitingToHangup trigger = dum::end UAS_Start -> UAS_OfferReliable trigger = onInvite-offer-rel action = app::onNewSession action = app::onOffer UAS_Start -> UAS_NoOfferReliable trigger = onInvite-rel action = app::onNewSession action = app::onOfferRequired UAS_OfferReliable -> UAS_FirstEarlyReliable trigger = dum::provideAnswer action = send::1xx-answer action = timer::1xx UAS_OfferReliable -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_OfferReliable -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_OfferReliable -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_NoOfferReliable -> UAS_NoOfferReliable trigger = dum::provideOffer action = store::offer UAS_NoOfferReliable -> UAS_FirstSentOfferReliable trigger = dum::provisional action = send::1xx-offer action = timer::1xx UAS_NoOfferReliable -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_NoOfferReliable -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_NoOfferReliable -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_FirstSentOfferReliable -> UAS_FirstSentOfferReliable trigger = onTimer1xx action = resend::1xx action = timer::1xx UAS_FirstSentOfferReliable -> UAS_EarlyReliable trigger = onPrack action = send::200P action = app::onAnswer UAS_FirstSentOfferReliable -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_FirstSentOfferReliable -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_FirstSentOfferReliable -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_FirstEarlyReliable -> UAS_FirstEarlyReliable trigger = onTimer1xx action = resend::1xx action = timer::1xx UAS_FirstEarlyReliable -> UAS_Accepted trigger = dum::accept action = queue::2xx UAS_FirstEarlyReliable -> UAS_EarlyReliable trigger = onPrack action = send::200P UAS_FirstEarlyReliable -> UAS_WaitingToTerminate trigger = dum::end UAS_FirstEarlyReliable -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_FirstEarlyReliable -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_FirstEarlyReliable -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_EarlyReliable -> UAS_EarlyReliable trigger = onPrack action = send::200P UAS_EarlyReliable -> UAS_EarlyReliable trigger = dum::provisional action = send::1xx action = timer::1xx UAS_EarlyReliable -> UAS_EarlyReliable trigger = onTimer1xx action = resend::1xx action = timer::1xx UAS_EarlyReliable -> UAS_Accepted trigger = dum::accept action = send::2xx action = timer::2xx UAS_EarlyReliable -> UAS_ReceivedUpdate trigger = onUpdate action = app::onOffer UAS_EarlyReliable -> UAS_SentUpdate trigger = dum::provideOffer action = send::UPDATE UAS_EarlyReliable -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyReliable -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyReliable -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_Accepted -> Connected trigger = onAck UAS_Accepted -> UAS_Accepted trigger = onCancel action = send::200C UAS_Accepted -> UAS_Accepted trigger = onPrack action = send::2xxP action = send::2xxI action = timer::2xx UAS_Accepted -> UAS_Accepted trigger = onTimer2xx action = resend::2xxI UAS_Accepted -> Terminated trigger = onTimerNoAck action = send::BYE UAS_Accepted -> UAS_WaitingToHangup trigger = dum::end UAS_Accepted -> Terminated trigger = onBye action = send::200B action = app::onTerminated action = dum::destroy UAS_SentUpdate -> UAS_SentUpdateAccepted trigger = dum::accept action = send::2xxI UAS_SentUpdate -> UAS_EarlyReliable trigger = on2xxU UAS_SentUpdate -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_SentUpdate -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_SentUpdate -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_SentUpdateAccepted -> UAS_Accepted trigger = on2xxU action = app::onAnswer UAS_SentUpdateAccepted -> UAS_Accepted trigger = onUpdateFailure action = app::onOfferRejected UAS_SentUpdateAccepted -> UAS_WaitingToHangup trigger = dum::end UAS_ReceivedUpdate -> UAS_ReceivedUpdateWaitingAnswer trigger = dum::accept action = queue::2xx UAS_ReceivedUpdate -> UAS_EarlyReliable trigger = dum::provideAnswer action = send::200U-answer UAS_ReceivedUpdate -> Terminated trigger = dum::end action = send::488U action = send::4xxI action = app::onTerminated action = dum::destroy UAS_ReceivedUpdate -> Terminated trigger = dum::reject action = send::488U action = send::4xxI action = app::onTerminated action = dum::destroy UAS_ReceivedUpdate -> Terminated trigger = dum::redirect action = send::488U action = send::3xxI action = app::onTerminated action = dum::destroy UAS_ReceivedUpdateWaitingAnswer -> UAS_Accepted trigger = dum::provideAnswer action = send::2xxU-answer action = send::2xxI UAS_ReceivedUpdateWaitingAnswer -> Terminated trigger = dum::end action = send::488U action = send::4xxI action = dum::destroy UAS_WaitingToTerminate -> Terminated trigger = onPrack action = send::4xx action = dum::destroy UAS_WaitingToHangup -> Terminated trigger = onPrack action = send::BYE UAS_WaitingToHangup -> Terminated trigger = onAck action = send::BYE UAS_WaitingToHangup -> Terminated trigger = onTimerNoAck action = send::BYE /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 20 10:52:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMeC-00042A-MW; Mon, 20 Mar 2006 10:50:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMeB-000420-VB for sip@ietf.org; Mon, 20 Mar 2006 10:50:19 -0500 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 1FLMe9-0007GL-K2 for sip@ietf.org; Mon, 20 Mar 2006 10:50:19 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Mar 2006 07:50:17 -0800 X-IronPort-AV: i="4.03,111,1141632000"; d="scan'208"; a="418252038:sNHT25790066" 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 k2KFoH7T012396; Mon, 20 Mar 2006 07:50:17 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 07:50:17 -0800 Received: from [10.21.97.35] ([10.21.97.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 07:50:13 -0800 Message-ID: <441ECF30.8010206@cisco.com> Date: Mon, 20 Mar 2006 10:50:08 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] Outbound and 410 References: <441C6BAA.2020106@nostrum.com> In-Reply-To: <441C6BAA.2020106@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 15:50:13.0740 (UTC) FILETIME=[F9F812C0:01C64C35] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Cullen Jennings , 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'm concerned about further overloading 481, which already has three overloads: (transaction doesn't exist for CANCEL, dialog doesn't exist, dialog usage doesn't exist.) Paul Adam Roach wrote: > I'm a slight bit concerned about the user experience that results from > the interaction between sending of a 410 because of a loss of a flow and > the way UAs interpret 410s. > > Imagine that I have a UA that doesn't know anything about the outbound > extension. It knows about 410s, though: 410s mean that the AOR they're > trying to use is forever gone. > > Cullen is using a UA that performs outbound to a proxy. > > So, I use my client to call Cullen. A flow ID is established at call > setup time, and written into our route. > > Somewhere in the middle of the call, something goes wrong on Cullen's > end, and his outbound connection to the proxy goes away. > > Now, I hang up. Because the flow indicated in my route is no longer any > good, I get a 410 response to my BYE. > > Now, my client knows what 410 means: it means "The requested resource is > no longer available at the server and no forwarding address is known. > This condition is expected to be considered permanent." > > Armed with this knowledge, it reacts to this error in a very reasonable > way: it puts up a dialog box, "The address for Cullen Jennings > is no longer valid, and no forwarding address > is known. This condition is expected to be permanent. Should I > permanently remove this address from your address book?" > > (Here I am thinking: "Oh. Of course. That's why the call was cut off: > Cullen suddenly ceased to exist.") > > If we want to avoid inventing another code for this situation, I would > argue that either 480 or 481 would likely result in more correct system > behavior than 410. In fact, the interaction between using 481 for this > purpose and RFC 3265 procedures appears to be more appropriate than the > other choices in this case. > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 20 11:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMoK-0002AW-5A; Mon, 20 Mar 2006 11:00:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMoI-00029T-OU for sip@ietf.org; Mon, 20 Mar 2006 11:00:46 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMoI-0007ab-Go for sip@ietf.org; Mon, 20 Mar 2006 11:00:46 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2KG0kVX033233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Mar 2006 10:00:46 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441ED1AD.1080205@nostrum.com> Date: Mon, 20 Mar 2006 10:00:45 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sip] draft-ietf-sip-fork-loop-fix-00.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 Just a quick note on draft-ietf-sip-fork-loop-fix-00.txt: > It is RECOMMENDED that proxies meet this requirement by > performing the Loop-Detection steps defined as an optional step in > Section 16.3 of RFC 3261. Other loop-detection mechanisms, such as > an adaptation of Knuth's algorithm, or the technique described in > [I-D.campen-sipping-stack-loop-detect] MAY be used. > This text suggests that, even when more efficient mechanism are available, the less efficient [O(m*n)] RFC3261 mechanism be employed. That is, by making the less efficient detection a RECOMMENDED level, and any other (presumably more efficient) mechanisms at MAY level, the draft implies that implementors should favor the less efficient implementation unless they have a really good reason. I would suggest making all mechanisms the same strength (which I think implies MAY): > Proxies MAY meet this requirement by performing the > Loop-Detection steps defined as an optional step in > Section 16.3 of RFC 3261. Proxies MAY also use other > loop-detection mechanisms, such as an adaptation of > Knuth's algorithm, or the technique described in > [I-D.campen-sipping-stack-loop-detect]. > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 20 11:16:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLN1v-00055t-59; Mon, 20 Mar 2006 11:14:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLN1t-00052K-Ct for sip@ietf.org; Mon, 20 Mar 2006 11:14:49 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLN1s-0008DV-5E for sip@ietf.org; Mon, 20 Mar 2006 11:14:49 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2KGElk7033913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Mar 2006 10:14:47 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441ED4F7.3030100@nostrum.com> Date: Mon, 20 Mar 2006 10:14:47 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Open issue in subnot-etags: suppress body or entire NOFITY? References: <441D8BC7.8000402@nokia.com> In-Reply-To: <441D8BC7.8000402@nokia.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Aki Niemi wrote: >Proposal 1) Same machanism for all. Clearly, the lowest common >denominator is, as Adam suggests, a Suppress-Body-If-Match header field >in a SUBSCRIBE. If this condition succeeds, the NOTIFY is sent but with >an empty body. Proposal is to use this mechanism for all cases above. > > ... >I'd personally go with proposal 1, simply to keep this sweet and simple. > > I agree. From an implementation perspective, it is (IMHO) much easier to treat all three situations the same. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 20 12:04:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNlr-0004YV-Lo; Mon, 20 Mar 2006 12:02:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNlq-0004Y0-Ke for sip@ietf.org; Mon, 20 Mar 2006 12:02:18 -0500 Received: from smtp112.iad.emailsrvr.com ([207.97.245.112] helo=smtp132.iad.emailsrvr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLNlp-0001qk-EY for sip@ietf.org; Mon, 20 Mar 2006 12:02:18 -0500 Received: from webmail.counterpath.com (webmail3.r1.iad.emailsrvr.com [10.238.10.11]) by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id C78E945A6C6; Mon, 20 Mar 2006 12:02:16 -0500 (EST) Received: from 130.129.133.240 (Webmail authenticated user derek@counterpath.com, derek@counterpath.com); by webmail.counterpath.com with HTTP; Mon, 20 Mar 2006 12:02:16 -0500 (EST) Message-ID: <1415.130.129.133.240.1142874136.webmail@130.129.133.240> Date: Mon, 20 Mar 2006 12:02:16 -0500 (EST) From: derek@counterpath.com To: vkg@lucent.com> X-Mailer: Webmail v3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: OK Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sip@ietf.org Subject: [Sip] Comment on sip-tls-use draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: derek@counterpath.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've given this a fairly detailed read. Its good that the issue of more explicit rules on certificate name matching is (finally) being addressed.= =20 It will be really nice to nail down what the certificate for a server far= m looks like. A few Comments: * In the introduction, why would Alice's possession of a certificate determine whether sip or sips is used in the registration? If Alice pins = a TLS connection to a server(Alice might implement sip-outbound, but pinned TLS w/ server certs only is already deployed) a sips uri would be appropriate. * In section 4, there is an assertion that: When endpoints use TLS, there aren't any checks at the SIP layer correlating the contents of the TLS certificate with the SIP headers. AFAIK, there is a requirement that endpoints match the request URI agains= t the certificate name. Also in section 4 there is an DNS poisoning attack where example.net hijacks example.com. This is not an effective attack unless a cert. has been compromised as the name presented in the certificate will not match the request uri. * using the via trail to see if a message has been compromised does not seem worthwhile, as there is nothing preventing the attacker from inserting a valid-looking via trail. * promoting a SIP URI to a SIPS uri seems like a nice thing for registrar= s to do as clients will not have to have knowledge of whether the registrar/proxy has correctly implemented sips. Admittedly, this is only an issue w/ bad registrar/proxy implementations. Thanks, Derek _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 20 13:29:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLP6s-0001kQ-4C; Mon, 20 Mar 2006 13:28:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMPY-0005g5-A5 for sip@ietf.org; Mon, 20 Mar 2006 10:35:12 -0500 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 1FLMPV-0006p6-Hy for sip@ietf.org; Mon, 20 Mar 2006 10:35:12 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162] (may be forged)) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2KFYi86028352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Mar 2006 09:34:44 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <441ECB93.1040008@estacado.net> Date: Mon, 20 Mar 2006 09:34:43 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] The Problem with PRACK References: <072C5B76F7CEAB488172C6F64B30B5E3013D7D20@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3013D7D20@xmb-rtp-20b.amer.cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 6801f129b9672ecbb1b9b6500e5aba4e X-Mailman-Approved-At: Mon, 20 Mar 2006 13:27:57 -0500 Cc: sip@ietf.org, jh@tutpro.com, christer.holmberg@ericsson.com, drage@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 Michael Hammer (mhammer) wrote: >Anyway, I haven't seen the 50+ state diagram from Vancouver either, but >it would be good to have that distributed on the mail list. I must have >missed that one if it was. > > Because the graphic doesn't work well on a mailing list, I've put it here in text format. If you want the visual impact of the graph that Rohan put up at IETF64, grab the PDF file at http://scm.sipfoundry.org/viewsvn/*checkout*/resiprocate/main/resip/dum/doc/dum-fsms1.pdf This comes from the Dialog Usage Manager in the resiprocate stack; the transition is denoted as "oldstate->newstate"; the trigger and subsequent actions are indicated following that line. UAC_Start -> UAC_Early trigger = on1xxI action = app::onNewSession action = timer::StaleCall action = app::onProvisional UAC_Start -> UAC_Early trigger = on1xxI-early action = app::onNewSession action = timer::StaleCall action = app::onProvisional action = app::onEarlyMedia UAC_Start -> UAC_EarlyWithOffer trigger = on1xxI-offer action = app::onNewSession action = timer::StaleCall action = app::onProvisional action = app::onOffer UAC_Start -> UAC_EarlyWithAnswer trigger = on1xxI-answer action = app::onNewSession action = timer::StaleCall action = app::onProvisional action = app::onAnswer action = send::PRACK UAC_Start -> UAC_Answered trigger = on2xxI-offer action = app::onNewSession action = app::onOffer action = app::onConnected UAC_Start -> Connected trigger = on2xxI-answer action = send::ACK action = app::onNewSession action = app::onAnswer action = app::onConnected UAC_Start -> Terminated trigger = on2xxI action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_Start -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_Start -> Terminated trigger = onRedirect action = app::onRedirected UAC_Start -> Assert trigger = dum::cancel action = assert UAC_Early -> UAC_Early trigger = on1xxI action = timer::StaleCall action = app::onProvisional action = send::PRACK UAC_Early -> UAC_Early trigger = on1xxI-early action = timer::StaleCall action = app::onProvisional action = app::onEarlyMedia UAC_Early -> UAC_EarlyWithOffer trigger = on1xxI-offer action = timer::StaleCall action = app::onProvisional action = app::onOffer UAC_Early -> UAC_EarlyWithAnswer trigger = on1xxI-answer action = timer::StaleCall action = app::onProvisional action = app::onAnswer action = send::PRACK UAC_Early -> UAC_Answered trigger = on2xxI-offer action = app::onOffer action = app::onConnected UAC_Early -> Connected trigger = on2xxI-answer action = send::ACK action = app::onAnswer action = app::onConnected UAC_Early -> Terminated trigger = on2xxI action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_Early -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_Early -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_Early -> Terminated trigger = onRedirect action = app::onRedirected UAC_Early -> Assert trigger = dum::provideAnswer action = assert UAC_Early -> Assert trigger = dum::provideOffer action = assert UAC_Early -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_EarlyWithOffer -> UAC_EarlyWithOffer trigger = on1xxI action = timer::StaleCall action = app::onProvisional action = send::PRACK UAC_EarlyWithOffer -> UAC_SentAnswer trigger = dum::provideAnswer action = send::PRACK-answer UAC_EarlyWithOffer -> Terminated trigger = on2xxI trigger = on2xxI-answer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_EarlyWithOffer -> Terminated trigger = onRedirect action = app::onRedirected UAC_EarlyWithOffer -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_EarlyWithOffer -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_EarlyWithOffer -> Assert trigger = dum::provideOffer action = assert UAC_EarlyWithOffer -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_EarlyWithAnswer -> UAC_EarlyWithAnswer trigger = on1xxI action = timer::StaleCall action = app::onProvisional action = send::PRACK UAC_EarlyWithAnswer -> Connected trigger = on2xxI action = send::ACK action = app::onConnected UAC_EarlyWithAnswer -> Terminated trigger = on2xxI-offer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_EarlyWithAnswer -> UAC_ReceivedUpdateEarly trigger = onUpdate action = app::onOffer UAC_EarlyWithAnswer -> UAC_SentUpdateEarly trigger = dum::provideOffer action = send::UPDATE UAC_EarlyWithAnswer -> Terminated trigger = onRedirect action = app::onRedirected UAC_EarlyWithAnswer -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_EarlyWithAnswer -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_EarlyWithAnswer -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_EarlyWithAnswer -> Assert trigger = dum::provideAnswer action = assert UAC_SentUpdateEarly -> UAC_EarlyWithAnswer trigger = on2xxU action = app::onAnswer UAC_SentUpdateEarly -> UAC_EarlyWithAnswer trigger = onUpdate action = send::491 UAC_SentUpdateEarly -> UAC_EarlyWithAnswer trigger = on491U action = app::onOfferRejected UAC_SentUpdateEarly -> UAC_SentUpdateConnected trigger = on2xxI action = send::ACK UAC_SentUpdateEarly -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_SentUpdateEarly -> Assert trigger = dum::provideAnswer action = assert UAC_SentUpdateEarly -> Assert trigger = dum::provideOffer action = assert UAC_SentUpdateEarly -> Terminated trigger = onRedirect action = app::onRedirected UAC_SentUpdateEarly -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_SentUpdateEarly -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_SentUpdateConnected -> Connected trigger = on2xxU action = app::onAnswer UAC_SentUpdateConnected -> Connected trigger = onUpdateFailure action = app::onOfferRejected UAC_SentUpdateConnected -> Connected trigger = on491U action = glare UAC_SentUpdateConnected -> Assert trigger = dum::cancel action = assert UAC_SentUpdateConnected -> Assert trigger = dum::provideAnswer action = assert UAC_SentUpdateConnected -> Assert trigger = dum::provideOffer action = assert UAC_SentUpdateConnected -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_ReceivedUpdateEarly -> Terminated trigger = onRedirect action = app::onRedirected UAC_ReceivedUpdateEarly -> UAC_EarlyWithAnswer trigger = dum::provideAnswer action = send::200U-answer UAC_ReceivedUpdateEarly -> UAC_EarlyWithAnswer trigger = dum::reject action = send::488U UAC_ReceivedUpdateEarly -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_ReceivedUpdateEarly -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_ReceivedUpdateEarly -> Assert trigger = dum::provideAnswer action = assert UAC_ReceivedUpdateEarly -> Assert trigger = dum::provideOffer action = assert UAC_Answered -> Connected trigger = dum::provideAnswer action = send::ACK-answer action = app::onConnected UAC_Answered -> Assert trigger = dum::provideOffer action = assert UAC_Answered -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_Answered -> Assert trigger = dum::cancel action = assert UAC_SentAnswer -> UAC_EarlyWithAnswer trigger = on2xxP UAC_SentAnswer -> Connected trigger = on2xxI action = send::ACK action = app::onConnected UAC_SentAnswer -> Terminated trigger = on1xxI-offer trigger = on1xxI-answer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_SentAnswer -> Terminated trigger = on2xxI-offer trigger = on2xxI-answer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_SentAnswer -> UAC_EarlyWithAnswer trigger = on1xxI action = timer::StaleCall action = app::onProvisional action = send::PRACK UAC_SentAnswer -> Terminated trigger = onRedirect action = app::onRedirected UAC_SentAnswer -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_SentAnswer -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_SentAnswer -> UAC_QueuedUpdate trigger = dum::provideOffer action = store::offer UAC_SentAnswer -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_SentAnswer -> Assert trigger = dum::provideAnswer action = assert UAC_QueuedUpdate -> UAC_SentUpdateEarly trigger = on2xxP action = send::UPDATE-offer UAC_QueuedUpdate -> SentUpdate trigger = on2xxI action = send::ACK action = app::onConnected action = send::UPDATE-offer UAC_QueuedUpdate -> Terminated trigger = on1xxI-offer trigger = on1xxI-answer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_QueuedUpdate -> Terminated trigger = on2xxI-offer trigger = on2xxI-answer action = send::ACK action = send::BYE action = app::onFailure action = app::onTerminated UAC_QueuedUpdate -> UAC_QueuedUpdate trigger = on1xxI action = timer::StaleCall action = app::onProvisional action = send::PRACK UAC_QueuedUpdate -> Terminated trigger = onRedirect action = app::onRedirected UAC_QueuedUpdate -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_QueuedUpdate -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated UAC_QueuedUpdate -> UAC_Cancelled trigger = dum::cancel action = timer::cancel UAC_QueuedUpdate -> Assert trigger = dum::provideAnswer action = assert UAC_QueuedUpdate -> Assert trigger = dum::provideOffer action = assert UAC_Cancelled -> Terminated trigger = onTimerCancel action = send::487 action = app::onTerminated UAC_Cancelled -> Terminated trigger = on2xxI trigger = on2xxI-offer trigger = on2xxI-answer action = send::ACK action = send::BYE action = app::onTerminated UAC_Cancelled -> Terminated trigger = onRedirect action = app::onRedirected UAC_Cancelled -> Terminated trigger = onInviteFailure trigger = onGeneralFailure action = app::onFailure action = app::onTerminated action = dum::destroy UAC_Cancelled -> UAC_Cancelled trigger = dum::cancel UAC_Cancelled -> Terminated trigger = dum::end action = send::BYE action = app::onTerminated Connected -> SentUpdate trigger = dum::provideOffer action = send::UPDATE Connected -> SentReinvite trigger = dum::provideOffer action = send::INVITE Connected -> SentReinviteNoOffer trigger = dum::requestOffer action = send::INVITE Connected -> ReceivedUpdate trigger = onUpdate action = app::onOffer Connected -> ReceivedReinvite trigger = onInvite-offer action = app::onOffer Connected -> ReceivedReinviteNoOffer trigger = onInvite action = app::onOfferRequired Connected -> Connected trigger = on2xxP Connected -> Connected trigger = on2xxI action = resend::ACK Connected -> Connected trigger = onTimer2xx action = resend::2xx Connected -> Connected trigger = onCancel action = send::200C Connected -> Terminated trigger = dum::end action = send::BYE Connected -> Terminated trigger = onBye action = send::200B action = app::onTerminated SentUpdate -> Connected trigger = on2xxU action = app::onAnswer SentUpdate -> Connected trigger = onUpdateFailure action = app::onOfferRejected SentUpdate -> SentUpdate trigger = onUpdate trigger = onInvite action = send::491 SentUpdate -> SentUpdateGlare trigger = on491U action = timer::491 SentUpdate -> Terminated trigger = onGeneralFailure action = app::onTerminated action = send::BYE SentUpdate -> Terminated trigger = dum::end action = send::BYE SentUpdateGlare -> SentUpdate trigger = onTimer491 action = resend::UPDATE SentUpdateGlare -> ReceivedUpdate trigger = onUpdate action = app::onOfferRejected action = app::onOffer SentUpdateGlare -> ReceivedReinvite trigger = onInvite-offer action = app::onOfferRejected action = app::onOffer SentUpdateGlare -> Terminated trigger = dum::end action = send::BYE SentReinvite -> Connected trigger = on2xxI-answer action = app::onAnswer action = send::ACK SentReinvite -> Connected trigger = on2xxI action = app::onIllegalNegotiation action = send::ACK SentReinvite -> Connected trigger = onInviteFailure action = app::onOfferRejected SentReinvite -> SentReinvite trigger = onInvite trigger = onUpdate action = send::491 SentReinvite -> SentReinviteGlare trigger = on491I action = timer::491 SentReinvite -> WaitingToTerminate trigger = dum::end SentReinviteGlare -> SentReinvite trigger = onTimer491 action = resend::INVITE SentReinviteGlare -> ReceivedUpdate trigger = onUpdate action = app::onOfferRejected action = app::onOffer SentReinviteGlare -> ReceivedReinvite trigger = onInvite-offer action = app::onOfferRejected action = app::onOffer SentReinviteGlare -> ReceivedReinviteNoOffer trigger = onInvite action = app::onOfferRejected action = app::onOfferRequired SentReinviteGlare -> Terminated trigger = dum::end action = send::BYE SentReinviteNoOffer -> SentReinviteAnswered trigger = on2xxI-offer action = app::onOffer SentReinviteNoOffer -> Connected trigger = on2xxI action = app::onIllegalNegotiation action = send::ACK SentReinviteNoOffer -> Connected trigger = onInviteFailure action = app::onOfferRequestRejected SentReinviteNoOffer -> SentReinviteNoOffer trigger = onInvite trigger = onUpdate action = send::491 SentReinviteNoOffer -> SentReinviteNoOfferGlare trigger = on491I action = timer::491 SentReinviteNoOffer -> WaitingToTerminate trigger = dum::end SentReinviteAnswered -> Connected trigger = dum::provideAnswer action = send::ACK-answer SentReinviteAnswered -> Terminated trigger = dum::end action = app::onTerminated action = send::BYE SentReinviteNoOfferGlare -> SentReinviteNoOffer trigger = onTimer491 action = resend::INVITE SentReinviteNoOfferGlare -> ReceivedUpdate trigger = onUpdate action = app::onOfferRequestRejected action = app::onOffer SentReinviteNoOfferGlare -> ReceivedReinvite trigger = onInvite action = app::onOfferRequestRejected action = app::onOffer SentReinviteNoOfferGlare -> ReceivedReinviteNoOffer trigger = onInvite action = app::onOfferRequestRejected action = app::onOfferRequired SentReinviteNoOfferGlare -> Terminated trigger = dum::end action = send::BYE ReceivedUpdate -> Connected trigger = dum::provideAnswer action = send::200U ReceivedUpdate -> Connected trigger = dum::reject action = send::488U ReceivedUpdate -> Terminated trigger = dum::end action = send::488U action = send::BYE ReceivedUpdate -> ReceivedUpdate trigger = onInvite trigger = onUpdate action = send::500 ReceivedReinvite -> Answered trigger = dum::provideAnswer action = send::200I action = timer::200I action = timer::NoAck ReceivedReinvite -> Connected trigger = dum::reject action = send::488U ReceivedReinvite -> Terminated trigger = dum::end action = send::488I action = send::BYE ReceivedReinvite -> ReceivedReinvite trigger = onInvite trigger = onUpdate action = send::500 Answered -> Answered trigger = onTimer2xx action = resend::2xx Answered -> WaitingToOffer trigger = dum::provideOffer action = store::offer Answered -> WaitingToRequestOffer trigger = dum::requestOffer Answered -> Connected trigger = onAck action = timer::NoAck action = app::onAckNotReceived Answered -> WaitingToHangup trigger = dum::end WaitingToOffer -> WaitingToOffer trigger = onTimer2xx action = resend::2xx WaitingToOffer -> SentUpdate trigger = onAck action = send::UPDATE-offer WaitingToOffer -> SentReinvite trigger = onAck action = send::INVITE-offer WaitingToOffer -> SentUpdate trigger = onTimerNoAck action = app::onOfferRejected action = send::UPDATE-offer WaitingToOffer -> SentReinvite trigger = onTimerNoAck action = app::onOfferRejected action = send::INVITE-offer WaitingToOffer -> WaitingToHangup trigger = dum::end WaitingToRequestOffer -> WaitingToRequestOffer trigger = onTimer2xx action = resend::2xx WaitingToRequestOffer -> SentUpdate trigger = onAck action = send::UPDATE-offer WaitingToRequestOffer -> SentReinvite trigger = onAck action = send::INVITE-offer WaitingToRequestOffer -> SentReinviteNoOffer trigger = onAck action = send::INVITE WaitingToRequestOffer -> SentUpdate trigger = onTimerNoAck action = app::onOfferRejected action = send::UPDATE-offer WaitingToRequestOffer -> SentReinvite trigger = onTimerNoAck action = app::onOfferRejected action = send::INVITE-offer WaitingToRequestOffer -> SentReinviteNoOffer trigger = onTimerNoAck action = app::onOfferRejected action = send::INVITE WaitingToRequestOffer -> WaitingToHangup trigger = dum::end ReceivedReinviteNoOffer -> ReceivedReinviteSentOffer trigger = dum::provideOffer action = send::200-offer action = timer::200I action = timer::NoAck ReceivedReinviteNoOffer -> Connected trigger = dum::reject action = send::488I ReceivedReinviteNoOffer -> Terminated trigger = dum::end action = send::488I action = send::BYE ReceivedReinviteNoOffer -> ReceivedReinviteNoOffer trigger = onInvite trigger = onUpdate action = send::500 ReceivedReinviteSentOffer -> Connected trigger = onAck-answer action = app::onAnswer ReceivedReinviteSentOffer -> Connected trigger = onAck action = app::onOfferRejected ReceivedReinviteSentOffer -> ReceivedReinviteSentOffer trigger = onTimer2xx action = resend::2xxI ReceivedReinviteSentOffer -> Connected trigger = onTimerNoAck action = app::onOfferRejected ReceivedReinviteSentOffer -> WaitingToHangup trigger = dum::end WaitingToTerminate -> Terminated trigger = on2xxI action = send::ACK action = send::BYE WaitingToTerminate -> Terminated trigger = onInviteFailure action = send::BYE WaitingToHangup -> Terminated trigger = onAck action = send::BYE WaitingToHangup -> Terminated trigger = onTimerNoAck action = send::BYE Terminated -> Terminated trigger = onResponse action = dum::destroy Terminated -> Terminated trigger = onRequest action = send::481 action = dum::destroy UAS_Start -> UAS_Offer trigger = onInvite-offer action = app::onNewSession action = app::onOffer UAS_Offer -> UAS_OfferProvidedAnswer trigger = dum::provideAnswer action = store::answer UAS_Offer -> UAS_EarlyOffer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_Offer -> Assert trigger = dum::accept action = assert UAS_Offer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_Offer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_Offer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_Offer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I UAS_Offer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I UAS_OfferProvidedAnswer -> UAS_Accepted trigger = dum::accept action = send::2xx-answer action = timer::2xx action = timer::NoAck action = app::onConnected UAS_OfferProvidedAnswer -> UAS_EarlyProvidedAnswer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_OfferProvidedAnswer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_OfferProvidedAnswer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_OfferProvidedAnswer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_OfferProvidedAnswer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I UAS_OfferProvidedAnswer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I UAS_Accepted -> Connected trigger = onAck UAS_Accepted -> UAS_Accepted trigger = onCancel action = send::200C UAS_Accepted -> UAS_Accepted trigger = onTimer2xx action = resend::2xxI UAS_Accepted -> Terminated trigger = onAck-answer action = send::BYE UAS_Accepted -> Terminated trigger = onTimerNoAck action = app::onAckNotReceived action = app::onTerminated action = send::BYE UAS_Accepted -> Terminated trigger = onBye action = app::onTerminated action = send::200B UAS_Accepted -> UAS_WaitingToHangup trigger = dum::end UAS_Accepted -> UAS_WaitingToOffer trigger = dum::provideOffer action = store::offer UAS_WaitingToOffer -> UAS_SentUpdate trigger = onAck action = send::UPDATE-offer UAS_WaitingToOffer -> SentReinvite trigger = onAck action = send::INVITE-offer UAS_WaitingToOffer -> UAS_WaitingToOffer trigger = onCancel action = send::200C UAS_WaitingToOffer -> UAS_WaitingToOffer trigger = onTimer2xx action = resend::2xxI UAS_WaitingToOffer -> Terminated trigger = onAck-answer action = send::BYE UAS_WaitingToOffer -> Terminated trigger = onTimerNoAck action = app::onAckNotReceived action = app::onTerminated action = send::BYE UAS_WaitingToOffer -> Terminated trigger = onBye action = app::onTerminated action = send::200B UAS_WaitingToOffer -> UAS_WaitingToHangup trigger = dum::end UAS_EarlyOffer -> UAS_EarlyOffer trigger = onTimer1xx action = resend::1xx UAS_EarlyOffer -> UAS_EarlyOffer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_EarlyOffer -> UAS_EarlyProvidedAnswer trigger = dum::provideAnswer action = store::answer UAS_EarlyOffer -> Assert trigger = dum::accept action = assert UAS_EarlyOffer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyOffer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyOffer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_EarlyOffer -> Terminated trigger = onCancel action = send::200C action = send::487I UAS_EarlyOffer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I UAS_EarlyProvidedAnswer -> UAS_EarlyProvidedAnswer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_EarlyProvidedAnswer -> UAS_Accepted trigger = dum::accept action = send::2xx-answer action = timer::2xx action = timer::NoAck action = app::onConnected UAS_EarlyProvidedAnswer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedAnswer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedAnswer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedAnswer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I UAS_EarlyProvidedAnswer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I UAS_Start -> UAS_NoOffer trigger = onInvite action = app::onNewSession action = app::onOfferRequired UAS_NoOffer -> UAS_ProvidedOffer trigger = dum::provideOffer action = store::offer UAS_NoOffer -> UAS_EarlyNoOffer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_NoOffer -> Assert trigger = dum::accept action = assert UAS_NoOffer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_NoOffer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_NoOffer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_NoOffer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I action = dum::destroy UAS_NoOffer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I action = dum::destroy UAS_ProvidedOffer -> UAS_EarlyProvidedOffer trigger = dum::provisional action = send::1xx-early action = timer::1xx UAS_ProvidedOffer -> UAS_AcceptedWaitingAnswer trigger = dum::accept action = send::2xxI-offer action = timer::2xx action = timer::NoAck UAS_ProvidedOffer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_ProvidedOffer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_ProvidedOffer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_ProvidedOffer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I action = dum::destroy UAS_ProvidedOffer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I action = dum::destroy UAS_EarlyNoOffer -> UAS_EarlyNoOffer trigger = onTimer1xx action = resend::1xx UAS_EarlyNoOffer -> UAS_EarlyNoOffer trigger = dum::provisional action = send::1xx action = timer::1xx UAS_EarlyNoOffer -> UAS_EarlyProvidedOffer trigger = dum::provideOffer action = store::offer UAS_EarlyNoOffer -> Assert trigger = dum::accept action = assert UAS_EarlyNoOffer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyNoOffer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyNoOffer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_EarlyNoOffer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I action = dum::destroy UAS_EarlyNoOffer -> Terminated trigger = onBye action = app::onTerminated action = send::200B action = send::487I action = dum::destroy UAS_EarlyProvidedOffer -> UAS_EarlyProvidedOffer trigger = dum::provisional action = send::1xx-early action = timer::1xx UAS_EarlyProvidedOffer -> UAS_AcceptedWaitingAnswer trigger = dum::accept action = send::2xxI-offer action = timer::2xx action = timer::NoAck UAS_EarlyProvidedOffer -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedOffer -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedOffer -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_EarlyProvidedOffer -> Terminated trigger = onCancel action = app::onTerminated action = send::200C action = send::487I action = dum::destroy UAS_EarlyProvidedOffer -> Terminated trigger = onTerminated trigger = onBye action = send::200B action = send::487I action = dum::destroy UAS_AcceptedWaitingAnswer -> Connected trigger = onAck-answer action = app::onAnswer UAS_AcceptedWaitingAnswer -> UAS_AcceptedWaitingAnswer trigger = onCancel action = send::200C UAS_AcceptedWaitingAnswer -> UAS_AcceptedWaitingAnswer trigger = onPrack action = send::2xxP action = send::2xxI-offer UAS_AcceptedWaitingAnswer -> Terminated trigger = onTimer2xx action = resend::2xxI UAS_AcceptedWaitingAnswer -> Terminated trigger = onTimerNoAck action = send::BYE UAS_AcceptedWaitingAnswer -> UAS_WaitingToHangup trigger = dum::end UAS_Start -> UAS_OfferReliable trigger = onInvite-offer-rel action = app::onNewSession action = app::onOffer UAS_Start -> UAS_NoOfferReliable trigger = onInvite-rel action = app::onNewSession action = app::onOfferRequired UAS_OfferReliable -> UAS_FirstEarlyReliable trigger = dum::provideAnswer action = send::1xx-answer action = timer::1xx UAS_OfferReliable -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_OfferReliable -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_OfferReliable -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_NoOfferReliable -> UAS_NoOfferReliable trigger = dum::provideOffer action = store::offer UAS_NoOfferReliable -> UAS_FirstSentOfferReliable trigger = dum::provisional action = send::1xx-offer action = timer::1xx UAS_NoOfferReliable -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_NoOfferReliable -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_NoOfferReliable -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_FirstSentOfferReliable -> UAS_FirstSentOfferReliable trigger = onTimer1xx action = resend::1xx action = timer::1xx UAS_FirstSentOfferReliable -> UAS_EarlyReliable trigger = onPrack action = send::200P action = app::onAnswer UAS_FirstSentOfferReliable -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_FirstSentOfferReliable -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_FirstSentOfferReliable -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_FirstEarlyReliable -> UAS_FirstEarlyReliable trigger = onTimer1xx action = resend::1xx action = timer::1xx UAS_FirstEarlyReliable -> UAS_Accepted trigger = dum::accept action = queue::2xx UAS_FirstEarlyReliable -> UAS_EarlyReliable trigger = onPrack action = send::200P UAS_FirstEarlyReliable -> UAS_WaitingToTerminate trigger = dum::end UAS_FirstEarlyReliable -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_FirstEarlyReliable -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_FirstEarlyReliable -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_EarlyReliable -> UAS_EarlyReliable trigger = onPrack action = send::200P UAS_EarlyReliable -> UAS_EarlyReliable trigger = dum::provisional action = send::1xx action = timer::1xx UAS_EarlyReliable -> UAS_EarlyReliable trigger = onTimer1xx action = resend::1xx action = timer::1xx UAS_EarlyReliable -> UAS_Accepted trigger = dum::accept action = send::2xx action = timer::2xx UAS_EarlyReliable -> UAS_ReceivedUpdate trigger = onUpdate action = app::onOffer UAS_EarlyReliable -> UAS_SentUpdate trigger = dum::provideOffer action = send::UPDATE UAS_EarlyReliable -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyReliable -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_EarlyReliable -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_Accepted -> Connected trigger = onAck UAS_Accepted -> UAS_Accepted trigger = onCancel action = send::200C UAS_Accepted -> UAS_Accepted trigger = onPrack action = send::2xxP action = send::2xxI action = timer::2xx UAS_Accepted -> UAS_Accepted trigger = onTimer2xx action = resend::2xxI UAS_Accepted -> Terminated trigger = onTimerNoAck action = send::BYE UAS_Accepted -> UAS_WaitingToHangup trigger = dum::end UAS_Accepted -> Terminated trigger = onBye action = send::200B action = app::onTerminated action = dum::destroy UAS_SentUpdate -> UAS_SentUpdateAccepted trigger = dum::accept action = send::2xxI UAS_SentUpdate -> UAS_EarlyReliable trigger = on2xxU UAS_SentUpdate -> Terminated trigger = dum::end action = send::4xxI action = app::onTerminated action = dum::destroy UAS_SentUpdate -> Terminated trigger = dum::reject action = send::4xxI action = app::onTerminated action = dum::destroy UAS_SentUpdate -> Terminated trigger = dum::redirect action = send::3xxI action = app::onTerminated action = dum::destroy UAS_SentUpdateAccepted -> UAS_Accepted trigger = on2xxU action = app::onAnswer UAS_SentUpdateAccepted -> UAS_Accepted trigger = onUpdateFailure action = app::onOfferRejected UAS_SentUpdateAccepted -> UAS_WaitingToHangup trigger = dum::end UAS_ReceivedUpdate -> UAS_ReceivedUpdateWaitingAnswer trigger = dum::accept action = queue::2xx UAS_ReceivedUpdate -> UAS_EarlyReliable trigger = dum::provideAnswer action = send::200U-answer UAS_ReceivedUpdate -> Terminated trigger = dum::end action = send::488U action = send::4xxI action = app::onTerminated action = dum::destroy UAS_ReceivedUpdate -> Terminated trigger = dum::reject action = send::488U action = send::4xxI action = app::onTerminated action = dum::destroy UAS_ReceivedUpdate -> Terminated trigger = dum::redirect action = send::488U action = send::3xxI action = app::onTerminated action = dum::destroy UAS_ReceivedUpdateWaitingAnswer -> UAS_Accepted trigger = dum::provideAnswer action = send::2xxU-answer action = send::2xxI UAS_ReceivedUpdateWaitingAnswer -> Terminated trigger = dum::end action = send::488U action = send::4xxI action = dum::destroy UAS_WaitingToTerminate -> Terminated trigger = onPrack action = send::4xx action = dum::destroy UAS_WaitingToHangup -> Terminated trigger = onPrack action = send::BYE UAS_WaitingToHangup -> Terminated trigger = onAck action = send::BYE UAS_WaitingToHangup -> Terminated trigger = onTimerNoAck action = send::BYE /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 20 13:29:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLP6v-0001l1-3C; Mon, 20 Mar 2006 13:28:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLN1Q-0004ZK-4Z for sip@ietf.org; Mon, 20 Mar 2006 11:14:20 -0500 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 1FLN1M-0008C8-QR for sip@ietf.org; Mon, 20 Mar 2006 11:14:20 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2KGEGZf037299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Mar 2006 10:14:16 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <441ED4D7.4070207@estacado.net> Date: Mon, 20 Mar 2006 10:14:15 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Open issue in subnot-etags: suppress body or entire NOFITY? References: <441D8BC7.8000402@nokia.com> In-Reply-To: <441D8BC7.8000402@nokia.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Mon, 20 Mar 2006 13:27:57 -0500 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 Aki Niemi wrote: >Proposal 1) Same machanism for all. Clearly, the lowest common >denominator is, as Adam suggests, a Suppress-Body-If-Match header field >in a SUBSCRIBE. If this condition succeeds, the NOTIFY is sent but with >an empty body. Proposal is to use this mechanism for all cases above. > > ... >I'd personally go with proposal 1, simply to keep this sweet and simple. > > I agree. From an implementation perspective, it is (IMHO) much easier to treat all three situations the same. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 20 14:23:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLPx1-0004s6-UG; Mon, 20 Mar 2006 14:21:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLPx1-0004s1-2I for sip@ietf.org; Mon, 20 Mar 2006 14:21:59 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLPwz-0007K7-JV for sip@ietf.org; Mon, 20 Mar 2006 14:21:59 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2KJLiv3005083; Mon, 20 Mar 2006 21:21:48 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 21:21:25 +0200 Received: from [10.241.59.15] ([10.241.59.15]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 21:21:25 +0200 Message-ID: <441F00B1.8010709@nokia.com> Date: Mon, 20 Mar 2006 21:21:21 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "ext Vijay K. Gurbani" Subject: Re: [Sip] Re: Comments to sip-outbound References: <441AD027.6030801@nokia.com><39229.12.151.41.2.1142614255.squirrel@12.151.41.2><441D7166.6030503@nokia.com> <24c93c1352cd57bde4924ff3309802f6@ekabal.com> <009001c64b80$bfb40160$31713b51@BEMBUSTER> <441DAB0F.9060105@nokia.com> <441E4AEB.7020904@lucent.com> In-Reply-To: <441E4AEB.7020904@lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 19:21:25.0576 (UTC) FILETIME=[7AF8CC80:01C64C53] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org, rohan@ekabal.com, fluffy@cisco.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 ext Vijay K. Gurbani wrote: > Aki Niemi wrote: >> But another thing occurred to me about the use of TCP keepalives. Since >> they are only hop-by-hop, they may not guarantee a flow is alive in the >> presence of proxy or proxies in the path to a registrar. At least not in >> the same way a CRLFx2 would. > > True; this has been the traditional rub against TCP keepalives. > If an intermediary (router) is down but the endpoints are up, the > endpoints may erroneously tear the connection down based on > this information (Unix Network Prorgamming by Fenner et al. > discusses this, as did the older TCP/IP Illustrated > by W. Richard Stevens). That's not really what I'm talking about here. A double-CRLF would receive an ack from the registrar, not the first proxy in the proxy chain. Therefore the question is, whether the sip-outbound keepalive is only meant to keep a NAT binding open (which is usually located between the UA and the first hop proxy), or should it really check the liveness of the flow all the way up to the registrar. 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 Mon Mar 20 14:40:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLQDU-0008Jb-6G; Mon, 20 Mar 2006 14:39:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLQDS-0008IC-Je for sip@ietf.org; Mon, 20 Mar 2006 14:38:58 -0500 Received: from web8906.mail.in.yahoo.com ([203.84.221.34]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLQDR-0007zl-Ex for sip@ietf.org; Mon, 20 Mar 2006 14:38:58 -0500 Received: (qmail 42445 invoked by uid 60001); 20 Mar 2006 19:38:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=23GWSj+hmu1EKC7/8lM2OncveX9xT3v4eFUMa408NgUyX9zU0I4hND75i2qpxMu7lAmfeeshOpcQ9mOEFOmaPCXMtjlANGy0FPWM6lPIOE1tGoOqTbgVO51GG0tivmH9nObL5jrSy1qM6A7iziFVWLrXCWioZ1ltoCYwgZ/6nx0= ; Message-ID: <20060320193838.42443.qmail@web8906.mail.in.yahoo.com> Received: from [210.214.40.22] by web8906.mail.in.yahoo.com via HTTP; Mon, 20 Mar 2006 19:38:38 GMT Date: Mon, 20 Mar 2006 19:38:38 +0000 (GMT) From: Thejeswara Reddy Subject: Re: [Sip] Comment on sip-tls-use draft To: derek@counterpath.com, vkg@lucent.com In-Reply-To: <1415.130.129.133.240.1142874136.webmail@130.129.133.240> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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="===============0342850268==" Errors-To: sip-bounces@ietf.org --===============0342850268== Content-Type: multipart/alternative; boundary="0-1412793537-1142883518=:42398" Content-Transfer-Encoding: 8bit --0-1412793537-1142883518=:42398 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit HI, Is it possible to convert sips (tls) to TCP (as proxy does from UDP to TCP), if the UAS wont support TLS, and the call is emrgency............ (dont want drop the call because of sips uri) Thanks. theja derek@counterpath.com wrote: I've given this a fairly detailed read. Its good that the issue of more explicit rules on certificate name matching is (finally) being addressed. It will be really nice to nail down what the certificate for a server farm looks like. A few Comments: * In the introduction, why would Alice's possession of a certificate determine whether sip or sips is used in the registration? If Alice pins a TLS connection to a server(Alice might implement sip-outbound, but pinned TLS w/ server certs only is already deployed) a sips uri would be appropriate. * In section 4, there is an assertion that: When endpoints use TLS, there aren't any checks at the SIP layer correlating the contents of the TLS certificate with the SIP headers. AFAIK, there is a requirement that endpoints match the request URI against the certificate name. Also in section 4 there is an DNS poisoning attack where example.net hijacks example.com. This is not an effective attack unless a cert. has been compromised as the name presented in the certificate will not match the request uri. * using the via trail to see if a message has been compromised does not seem worthwhile, as there is nothing preventing the attacker from inserting a valid-looking via trail. * promoting a SIP URI to a SIPS uri seems like a nice thing for registrars to do as clients will not have to have knowledge of whether the registrar/proxy has correctly implemented sips. Admittedly, this is only an issue w/ bad registrar/proxy implementations. Thanks, Derek _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------------------------- Jiyo cricket on Yahoo! India cricket Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-1412793537-1142883518=:42398 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit HI,

         Is it possible to convert  sips (tls) to TCP (as proxy does from UDP to TCP), if the UAS wont support TLS, and the call is emrgency............ (dont want drop the call because of sips uri)

Thanks.
theja

derek@counterpath.com wrote:

I've given this a fairly detailed read. Its good that the issue of more
explicit rules on certificate name matching is (finally) being addressed.
It will be really nice to nail down what the certificate for a server farm
looks like.

A few Comments:

* In the introduction, why would Alice's possession of a certificate
determine whether sip or sips is used in the registration? If Alice pins a
TLS connection to a server(Alice might implement sip-outbound, but pinned
TLS w/ server certs only is already deployed) a sips uri would be
appropriate.

* In section 4, there is an assertion that:

When endpoints use TLS, there aren't any checks at the SIP layer
correlating the contents of the TLS certificate with the SIP headers.

AFAIK, there is a requirement that endpoints match the request URI against
the certificate name.

Also in section 4 there is an DNS poisoning attack where example.net
hijacks example.com. This is not an effective attack unless a cert. has
been compromised as the name presented in the certificate will not match
the request uri.

* using the via trail to see if a message has been compromised does not
seem worthwhile, as there is nothing preventing the attacker from
inserting a valid-looking via trail.

* promoting a SIP URI to a SIPS uri seems like a nice thing for registrars
to do as clients will not have to have knowledge of whether the
registrar/proxy has correctly implemented sips. Admittedly, this is only
an issue w/ bad registrar/proxy implementations.

Thanks,

Derek



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

Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-1412793537-1142883518=:42398-- --===============0342850268== 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 --===============0342850268==-- From sip-bounces@ietf.org Mon Mar 20 15:24:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLQu9-0006Ln-1H; Mon, 20 Mar 2006 15:23:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLQu8-0006Li-CS for sip@ietf.org; Mon, 20 Mar 2006 15:23:04 -0500 Received: from smtp122.iad.emailsrvr.com ([207.97.245.122] helo=smtp132.iad.emailsrvr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLQu8-0001qc-4p for sip@ietf.org; Mon, 20 Mar 2006 15:23:04 -0500 Received: from webmail.counterpath.com (webmail4.r2.iad.emailsrvr.com [10.238.10.12]) by relay2.r2.iad.emailsrvr.com (SMTP Server) with ESMTP id 7741948946C; Mon, 20 Mar 2006 15:23:03 -0500 (EST) Received: from 130.129.133.240 (Webmail authenticated user derek@counterpath.com, derek@counterpath.com); by webmail.counterpath.com with HTTP; Mon, 20 Mar 2006 15:23:03 -0500 (EST) Message-ID: <1705.130.129.133.240.1142886183.webmail@130.129.133.240> Date: Mon, 20 Mar 2006 15:23:03 -0500 (EST) Subject: Re: [Sip] Comment on sip-tls-use draft From: derek@counterpath.com To: "Thejeswara Reddy" X-Mailer: Webmail v3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: OK Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org, vkg@lucent.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: derek@counterpath.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I believe the automatic promotion only applied to the contact of the UAC; it could be scoped to REGISTER. Promotion shouldn't be applied to request-uris. If a UAC is making an emergency call, SIP vs SIPS is under the UAC's cont= rol. -----Original Message----- From: "Thejeswara Reddy" Sent: Mon, March 20, 2006 2:38 pm To: derek@counterpath.com, vkg@lucent.com Cc: sip@ietf.org Subject: Re: [Sip] Comment on sip-tls-use draft HI, Is it possible to convert sips (tls) to TCP (as proxy does from UDP to TCP), if the UAS wont support TLS, and the call is emrgency............ (dont want drop the call because of sips uri) Thanks. theja derek@counterpath.com wrote: I've given this a fairly detailed read. Its good that the issue of more explicit rules on certificate name matching is (finally) being addressed. It will be really nice to nail down what the certificate for a server far= m looks like. A few Comments: * In the introduction, why would Alice's possession of a certificate determine whether sip or sips is used in the registration? If Alice pins = a TLS connection to a server(Alice might implement sip-outbound, but pinned TLS w/ server certs only is already deployed) a sips uri would be appropriate. * In section 4, there is an assertion that: When endpoints use TLS, there aren't any checks at the SIP layer correlating the contents of the TLS certificate with the SIP headers. AFAIK, there is a requirement that endpoints match the request URI agains= t the certificate name. Also in section 4 there is an DNS poisoning attack where example.net hijacks example.com. This is not an effective attack unless a cert. has been compromised as the name presented in the certificate will not match the request uri. * using the via trail to see if a message has been compromised does not seem worthwhile, as there is nothing preventing the attacker from inserting a valid-looking via trail. * promoting a SIP URI to a SIPS uri seems like a nice thing for registrar= s to do as clients will not have to have knowledge of whether the registrar/proxy has correctly implemented sips. Admittedly, this is only an issue w/ bad registrar/proxy implementations. Thanks, Derek _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------------------------- Jiyo cricket on Yahoo! India cricket Yahoo! Messenger Mobile Stay in touch with your buddies all the time. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 20 18:01:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTLs-0003IU-EI; Mon, 20 Mar 2006 17:59:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTLo-0003Cm-S2 for sip@ietf.org; Mon, 20 Mar 2006 17:59:48 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLTFK-0007cK-E8 for sip@ietf.org; Mon, 20 Mar 2006 17:53:06 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2006 14:52:49 -0800 X-IronPort-AV: i="4.03,112,1141632000"; d="scan'208"; a="1786620038:sNHT1354874680" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2KMql1p018396; Mon, 20 Mar 2006 14:52:47 -0800 (PST) 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.211); Mon, 20 Mar 2006 14:52:43 -0800 Received: from [10.89.16.53] ([10.89.16.53]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 14:52:43 -0800 Message-ID: <441E2CC7.9020802@cisco.com> Date: Sun, 19 Mar 2006 23:17:11 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khare, Anir" Subject: Re: [Sip] [query] service level capabilities spefifications between different SIP entities References: <6A960E377BE21549A178517AB49B00A7032A42D2@dlee06.ent.ti.com> In-Reply-To: <6A960E377BE21549A178517AB49B00A7032A42D2@dlee06.ent.ti.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Mar 2006 22:52:43.0232 (UTC) FILETIME=[FF719600:01C64C70] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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. Paul Khare, Anir wrote: > 3261 provides mechanisms to advertise capabilities between the > interacting SIP entities. E.g. SIP header fields like require etc. The > capabilities exchanged are essentially related to SIP level artifacts > e.g. a particular SIP method supported or a particular SIP extensions > specified in RFCs supported. However there are no mechanisms available > to specify capabilities related to distributed services which use SIP as > signaling mechanism to coordinate between different services entities. > Hence these SIP entities do not necessarily interoperate even if all of > them strictly comply to SIP standards for transporting service > interactions. Some standard call flows and best practices are specified > in RFCs, however there are no standard ways of specifying service level > capabilities of a SIP entity and the associated call flows that it can > support. Not in 3261, which is why there are other RFCs and drafts that extend it. > SDP focuses on end point to end point negotiation of some service > attributes, however there is no semantics anticipated related to > capabilities negotiation with intermediaries. RFC 3959/3960 suggests > some mechanisms during “early media” phase of the session. I don't see that those RFCs are especially relevant to the discussion. However RFC3312 is applicable to certain kinds of media service attributes. You can work on negotiating preconditions with multiple candidate target UEs and settle on the one that can (first) meet your needs. > SIP is rendezvous protocol, this means existence of intermediaries is > central part of the architecture (in peer to peer SIP the definition of > intermediaries is slightly diluted). Intermediaries are essentially > envisaged for finding the end points and routing communication between > them. RFC3840 suggests that end points can externalize some information > (during registration time) in order to influence this routing. Yup. This is a mechanism that has yet to see much use. None of these mechanisms is perfect, including this one that is far from perfect. But this one, like the others, brings something to the table, that may be used when appropriate. > In non- peer to peer models, SIP proxies provide more than the basic > rendezvous functions and it may be useful to have some unified mechanism > for service level negotiations between end points and intermediaries or > between intermediaries. I think there is considerable disagreement over what kinds of services are appropriate to be provided by intermediate nodes. As has been mentioned elsewhere, the work on end-to-middle policy exchange may be applicable. > If this is available then a given SIP end point will be able to > dynamically participate in different service environments, by > dynamically recognizing call flows/capabilities in a particular service > environment. I am still seeking enough concrete examples of these "service environments" to be able to infer the concept that is intended. > Are there any existing mechanisms specified in any RFCs which can deal > with these issues. If not, will addition of those be inline with the > overall SIP architecture? Some mentioned above. > Standardization of call flows across all service environments could be > another alternative way to look at this; however it will lot difficult > to realize and may not be inline with the spirit of SIP as an open > signaling protocol. Sounds like a bad idea, and doesn't really solve the problem. You can write down call flows for different cases, but they may be impossible to realize. Each node on the path needs to make a decision about what to do based on information available. In general it doesn't know which call flow it should be following. > Any clarifications, suggestions on this topic are appreciated. > > > > Thanks, > > Anir Khare > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 20 19:29:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUiy-0006gM-Se; Mon, 20 Mar 2006 19:27:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUix-0006gE-34 for sip@ietf.org; Mon, 20 Mar 2006 19:27:47 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLUit-0004DK-Js for sip@ietf.org; Mon, 20 Mar 2006 19:27:47 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2L0QJt5014275 for ; Tue, 21 Mar 2006 02:26:20 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 02:26:33 +0200 Received: from [10.241.59.12] ([10.241.59.12]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 21 Mar 2006 02:26:33 +0200 Message-ID: <441F4836.5050107@nokia.com> Date: Tue, 21 Mar 2006 02:26:30 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2006 00:26:33.0630 (UTC) FILETIME=[1B6C23E0:01C64C7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] Update to RFC3329, aka Security Agreement X-BeenThere: sip@ietf.org X-Mailman-Version: 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, During the past couple of years, there have been a few reported issues on RFC 3329, based on implementation experience. I've gathered the set of issues in an I-D: http://www.ietf.org/internet-drafts/draft-niemi-rfc3329-issues-00.txt We've already talked about rfc3329bis among the authors, and we feel this would be appropriate in order to straighten out the issues and improve interop. Any comments are welcome. 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 Mon Mar 20 19:50:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLV3O-0001fc-E4; Mon, 20 Mar 2006 19:48:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLV3M-0001cz-Si for sip@ietf.org; Mon, 20 Mar 2006 19:48:52 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLV3L-0004xz-L4 for sip@ietf.org; Mon, 20 Mar 2006 19:48:52 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2L0mlv0023535; Mon, 20 Mar 2006 18:48:47 -0600 (CST) Received: from [192.11.172.14] (vkg.lra.lucent.com [192.11.172.14] (may be forged)) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2L0mlC04681; Mon, 20 Mar 2006 18:48:47 -0600 (CST) Message-ID: <441F4D6F.6020309@lucent.com> Date: Mon, 20 Mar 2006 18:48:47 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thejeswara Reddy Subject: Re: [Sip] Comment on sip-tls-use draft References: <20060320193838.42443.qmail@web8906.mail.in.yahoo.com> In-Reply-To: <20060320193838.42443.qmail@web8906.mail.in.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Thejeswara Reddy wrote: > HI, > > Is it possible to convert sips (tls) to TCP (as proxy does > from UDP to TCP), if the UAS wont support TLS, and the call is > emrgency............ (dont want drop the call because of sips uri) Generally speaking, downgrading security in this manner is not recommended. The reasons we switch transports from UDP to TCP -- namely, congestion control, fragmentation, etc. -- are much different from downgrading sips to sip. I dare say proxies and user agent servers will have procedures and policies in place to handle SOS calls, regardless of transport. The ecrit WG discusses some of these issues. 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 Mon Mar 20 19:57:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLV9j-00071t-VK; Mon, 20 Mar 2006 19:55:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLV9i-0006zZ-4a for sip@ietf.org; Mon, 20 Mar 2006 19:55:26 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLV9f-0005I7-N2 for sip@ietf.org; Mon, 20 Mar 2006 19:55:26 -0500 Received: from dhcp-wireless-134-205.ietf65.org ([130.129.134.205]) by dns.aliantmedia.net with esmtpa (Exim 4.52) id 1FLV9Y-0005Op-4X; Mon, 20 Mar 2006 18:55:19 -0600 Message-ID: <441F4EF1.6070304@ntt-at.com> Date: Mon, 20 Mar 2006 16:55:13 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Update to RFC3329, aka Security Agreement References: <441F4836.5050107@nokia.com> In-Reply-To: <441F4836.5050107@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Aki; I just want to thank you for coming up with this draft. I heard some complaints resulting from the current RFC due to the lack of clarity and hopefully this is going to solve some of the reoccurring issues due to the lack of clarity. Regards Shida Aki Niemi wrote: > All, > > During the past couple of years, there have been a few reported issues > on RFC 3329, based on implementation experience. > > I've gathered the set of issues in an I-D: > http://www.ietf.org/internet-drafts/draft-niemi-rfc3329-issues-00.txt > > We've already talked about rfc3329bis among the authors, and we feel > this would be appropriate in order to straighten out the issues and > improve interop. Any comments are welcome. > > 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 From sip-bounces@ietf.org Mon Mar 20 22:36:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLXdp-00076T-EF; Mon, 20 Mar 2006 22:34:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLXdn-00076N-Qf for sip@ietf.org; Mon, 20 Mar 2006 22:34:39 -0500 Received: from xproxy.gmail.com ([66.249.82.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLXdk-0002qp-Hm for sip@ietf.org; Mon, 20 Mar 2006 22:34:39 -0500 Received: by xproxy.gmail.com with SMTP id h29so910605wxd for ; Mon, 20 Mar 2006 19:34:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=j0DQMW1hPmZF8MM6pGtqDCef18eJ2RMnSLfexCJGh3/gisoZHWfYx1c3BFTA7nSM5oZDc6onpgyED1FatSSozojU08Sb8JMSLFXZQkxRGGYFER242L0XjpZBzOGocmWAH2UoX+uRVRTFaaZFy/lewYDxm8JO3ckysLLU51TOcjY= Received: by 10.70.123.2 with SMTP id v2mr61673wxc; Mon, 20 Mar 2006 19:34:35 -0800 (PST) Received: by 10.70.118.8 with HTTP; Mon, 20 Mar 2006 19:34:35 -0800 (PST) Message-ID: Date: Tue, 21 Mar 2006 06:34:35 +0300 From: "Adishesh M" To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 2.0 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] Check this out X-BeenThere: sip@ietf.org X-Mailman-Version: 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 there. I don't usually send these on but you're going to want to see this. Want an ipod nano? http://giftresource123.com/?r=3DAVGEQigpAiI3CGkMCyUG&i=3Dgmail&z=3D1&tc=3D2 Lets give it a shot. Are you game? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 21 02:24:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLbCP-0004JR-Ox; Tue, 21 Mar 2006 02:22:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLbCN-0004I2-3E for sip@ietf.org; Tue, 21 Mar 2006 02:22:35 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLbBl-0001Yk-64 for sip@ietf.org; Tue, 21 Mar 2006 02:21:59 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2L7bkP1008866 for ; Tue, 21 Mar 2006 00:37:46 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k2L7bqEC022931 for ; Tue, 21 Mar 2006 01:37:53 -0600 (CST) Received: from motorola.com ([10.232.117.39]) by ZMY16EXM66.ds.mot.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 15:21:53 +0800 Message-ID: <441FABEB.8090901@motorola.com> Date: Tue, 21 Mar 2006 13:01:55 +0530 From: Preeti agarwal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org References: <018d01c63816$63923500$b2b04c0a@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2006 07:21:53.0707 (UTC) FILETIME=[20F21FB0:01C64CB8] X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] Presence RLS X-BeenThere: sip@ietf.org X-Mailman-Version: 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, This is regarding Presence RLS . 1. When creating Resource list document, the service uri for the resource list would be with "sip:uri@domain.com" or "uri@domain.com" ? 2. The entry URI for the same should be with "sip:presentity@domain.com" or without sip: i.e "presentity@domain.com" I am referring draft-ietf-simple-xcap-08, where it has user sip: for both. Would like to know whether sip: is mandatory in both the cases. Thanks, Priti _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 21 03:13:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLbxW-0004Or-LE; Tue, 21 Mar 2006 03:11:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLbxV-0004Om-2a for sip@ietf.org; Tue, 21 Mar 2006 03:11:17 -0500 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLbxT-0003Hu-P4 for sip@ietf.org; Tue, 21 Mar 2006 03:11:17 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 81B0974065 for ; Tue, 21 Mar 2006 09:11:14 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16582-01-42 for ; Tue, 21 Mar 2006 09:11:14 +0100 (CET) Received: from dhcp-wavelan-v-112.publik.su.se (dhcp-wavelan-v-112.publik.su.se [193.10.145.112]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 23D4774002 for ; Tue, 21 Mar 2006 09:11:14 +0100 (CET) From: Fredrik Thulin To: sip@ietf.org Date: Tue, 21 Mar 2006 09:11:07 +0100 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603210911.07053.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.665 tagged_above=-99 required=7 tests=[BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] GRUU draft: Record routing X-BeenThere: sip@ietf.org X-Mailman-Version: 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 understand that the Record routing in GRUU draft 07 was discussed during the SIP session yesterday. Unfortunately I could not follow that because the audio streaming wasn't working (for me at least) during the GRUU presentation, but I am very interested in hearing about the reasons for the home proxy to do Record-Route for the purpose of handling mid-dialog requests. 1) Isn't the Record-Route redundant since the GRUU by definition "routes to a server that can make sure the request is delivered to the UA instance"? 2) Why is it necessary to make all in-dialog requests use the same reg-id if the client (using outbound) have multiple active contacts? Isn't it sufficient to make sure the requests are routed to the same UA instance? The 'grid' parameter makes it possible for the client to know the context already. I would greatly appreciate if someone could inform me of what was said on this topic yesterday, since I can't really figure out why this is needed. Thanks /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 21 04:55:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdYT-0006rP-Ro; Tue, 21 Mar 2006 04:53:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdYT-0006ql-58 for sip@ietf.org; Tue, 21 Mar 2006 04:53:33 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLdU7-0007Lu-Fx for sip@ietf.org; Tue, 21 Mar 2006 04:49:04 -0500 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2LA4pHI011175 for ; Tue, 21 Mar 2006 03:04:51 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k2LA1Ht0015006 for ; Tue, 21 Mar 2006 04:01:19 -0600 (CST) 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] Presence RLS Date: Tue, 21 Mar 2006 17:48:59 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0110ED68@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Presence RLS Thread-Index: AcZMuIAIWFIL7INqTXeuQ2jMfNIqDwAE+1Lg From: "Avasarala Ranjit-A20990" To: "Agarwalla Priti-Q16972" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE 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 Hi SIP could be one kind of service request. Generally XCAP resources are HTTP resources. So the resource uri could be even http: too, not necessarily sip. =20 Regards=20 Ranjit=20 -----Original Message----- From: Agarwalla Priti-Q16972=20 Sent: Tuesday, March 21, 2006 3:32 PM To: sip@ietf.org Subject: [Sip] Presence RLS Hi All, This is regarding Presence RLS . 1. When creating Resource list document, the service uri for the resource list would be with "sip:uri@domain.com" or "uri@domain.com" ? 2. The entry URI for the same should be with "sip:presentity@domain.com" or without sip: i.e "presentity@domain.com" I am referring draft-ietf-simple-xcap-08, where it has user sip: for both. Would like to know whether sip: is mandatory in both the cases. Thanks, Priti _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 21 08:49:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhCe-0004bl-69; Tue, 21 Mar 2006 08:47:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhCd-0004bg-0P for sip@ietf.org; Tue, 21 Mar 2006 08:47:15 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhCa-0008HX-Gn for sip@ietf.org; Tue, 21 Mar 2006 08:47:14 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2LDl76W028934; Tue, 21 Mar 2006 15:47:09 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 15:46:00 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 15:46:00 +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] The Problem with PRACK Date: Tue, 21 Mar 2006 15:45:58 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0219B09D@esebe103.NOE.Nokia.com> In-Reply-To: <441ECCBD.1080402@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcZMNKV3rWII1SXrTWqoSHf4oyfFCwAsCXhg From: To: , X-OriginalArrivalTime: 21 Mar 2006 13:46:00.0391 (UTC) FILETIME=[C9D70570:01C64CED] X-Spam-Score: 0.2 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org, jh@tutpro.com, drage@lucent.com, christer.holmberg@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 Hi, >>>In Vancouver, Rohan put up a slide to demonstrate=20 >>>this issue graphically, but its impact hasn't been=20 >>>shared on the list. To that end, I'll point out that=20 >>>implementing the offer/answer procedures with PRACK=20 >>>requires a state machine with at least 52 states and=20 >>>329 transitions. That's a *lot* of code, and the=20 >>>chances of getting it all right are pretty close to=20 >>>zero. >> If that is the case, I would really ask that slide=20 >> with explanations To be published in SIP mailing list.=20 >> For instance I was not attending Vancouver meeting,=20 >> so I am currently lacking this piece of information. > Because the graphic doesn't work well on a mailing list,=20 > I've put it here in text format. If you want the visual=20 > impact of the graph that Rohan put up at IETF64, grab the=20 > PDF file... Thanks. This morning I had a look into the state diagram both in text and graphical format. > I would especially like to be explained where this=20 > multitude of states and transitions come from for=20 > sending offers/answers in PRACK, especially when=20 > compared to a solution where those could only be=20 > sent in UPDATE. To my surprise, amongst all the referred 329 transitions I found only 15 to be related to PRACK method. Further on I could not find any transition related to sending a PRACK with offer and only one single transition for sending a PRACK with answer. So after all, the apparent complexity of this state machine had no relation to sending offers=20 or answers within PRACK ! Deprecating offers within PRACK=20 would have absolutely no impact to this state diagram. Please tell me if I am wrong with this. After some study of the state diagram I now understand a bit better where those 52 states and 329 transitions come from. This is the result from my initial analysis: 1. This state diagram covers both UAC and UAS state machines. So it is not a single state machine at all. 2. The state machines do not contain only session setup like I expected. It also covers mid-dialog requests like re-INVITEs, mid-dialog UPDATEs and BYEs for terminating the session. 3. A big number of state transitions are related to=20 cancelling and terminating the dialogs either before or after the session has been moved to Connected state. In theory the session setup state machine could be cut =20 to half by deprecating offerless INVITEs. This is the source of most of the complexity in the state machine. But like discussed earlier in this thread the offerless INVITE has certain applications and is probably widely deployed, deprecating it can probably not be done generally. (In 3GPP they just simply mandate the INVITE to contain an offer,=20 which makes the life for implementors much easier. INVITE without offer will always be rejected with 4xx response.) Further on what clutters the UAC part of the state diagram is the fact that in the UAC_Start state the UAC might have sent the INVITE either with or without offer. I would rather redraw the diagram so that the UAC_Start state would be an idle state from which there would be transitions to two states like UAC_Offer and UAC_NoOffer. UAS part of the state diagram has been created that way, which makes it much clearer. The bottom line is that I do not think this state diagram really provided much input for making decisions about what to do with offer/answer in PRACK. Regards, Erkki ____________________________________ Erkki Koivusalo Nokia Mobile Software tel:+358 40 7571197 mailto:erkki.koivusalo@nokia.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 From sip-bounces@ietf.org Tue Mar 21 09:47:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLi7Y-0000VK-5B; Tue, 21 Mar 2006 09:46:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLi7X-0000V5-5k for sip@ietf.org; Tue, 21 Mar 2006 09:46:03 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLi7V-0002Cl-RQ for sip@ietf.org; Tue, 21 Mar 2006 09:46:03 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 21 Mar 2006 06:46:02 -0800 X-IronPort-AV: i="4.03,114,1141632000"; d="scan'208"; a="1786871234:sNHT30062356" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2LEk1Yg029244 for ; Tue, 21 Mar 2006 06:46:01 -0800 (PST) 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.211); Tue, 21 Mar 2006 06:46:01 -0800 Received: from [130.129.128.208] ([10.89.20.121]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 06:46:00 -0800 Message-ID: <442011A8.4020008@cisco.com> Date: Tue, 21 Mar 2006 09:46:00 -0500 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: 21 Mar 2006 14:46:00.0972 (UTC) FILETIME=[2BF414C0:01C64CF6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Sip] comments on sip-connected-identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org John, Firstly, this draft generally looks very good. Secondly, on the issue of UPDATE without offers, I believe it is fine to do this. Though not in RFC3311, this was part of the original conceived use of UPDATE (see http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt). We decided towards the end of the development to focus on the session update aspects of this. However, I think its fine to use UPDATE in this fashion, as long as the peer in the dialog indicates support for this usage of UPDATE (through the dialogURIChange tag). Minor comment - option tags are actually case insensitive, so its inappropriate to define them using camel case. I'd also suggest a shorter tag - id-change. Reading the document, it occurred to me that there is another possible solution for connected identity in the response to the invite. The draft says this: > The Contact header field provides a contact URI, which may not > reveal the identity (Address of Record) of the user on whose > behalf the response is sent. actually, if the UAS supports GRUU, it will in fact reveal the identity of the user. The GRUU is normally constructed as: sip:aor@domain;gruu;opaque=blob the GRUU spec says that stripping opaque yields the AOR of the user corresponding to the gruu. This form isn't used when the gruu is anonymous, but of course in such cases you can't get identity from it anyway. Usage of the gruu for identity conveyance has an interesting security property. Unlike To/From, its actually used for request routing. If an invalid value is placed in the request, any mid-dialog signaling will be misrouted and rejected. Thus, there are (some) safeguards against falsifying it. I need to noodle some more on how this fits in, but it is something we should consider. 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 Mar 21 11:04:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjJO-0001GR-UK; Tue, 21 Mar 2006 11:02:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjJO-0001GM-5U for sip@ietf.org; Tue, 21 Mar 2006 11:02:22 -0500 Received: from smtp112.iad.emailsrvr.com ([207.97.245.112] helo=smtp132.iad.emailsrvr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjJN-0005Ry-Nq for sip@ietf.org; Tue, 21 Mar 2006 11:02:22 -0500 Received: from bremen (unknown [64.251.86.193]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: derek@counterpath.com) by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id 765B445AC9E; Tue, 21 Mar 2006 11:02:20 -0500 (EST) From: "Derek MacDonald" To: Date: Tue, 21 Mar 2006 08:02:19 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcZNANTiS8K9T7uHTKC5ct1GeZeODQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20060321160220.765B445AC9E@relay1.r1.iad.emailsrvr.com> X-Virus-Scanned: OK X-Spam-Score: 1.1 (+) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Cc: sip@ietf.org Subject: [Sip] Comments on sip-response-identity X-BeenThere: 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="===============0490894793==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0490894793== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C64CBD.C7CEB320" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C64CBD.C7CEB320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Feng, There are some interesting approaches in this draft. The main issue still seems to be how a proxy(response identity service) trusts a response enough to sign it. A few specific comments: * for DAS how does a proxy trust a given response enough to sign it? One straw-man approach is: To use DAS, a UAS must register over a secure channel. The proxy will authenticate the user using digest challenge and a shared secret. For TLS, only one identity will be allowed per TLS session. Only when these requirments are met can a proxy provide responder identity using DAS. This is similar to how a proxy can claim SIPS for an aor even if the UA in question does not have a certificate. One consequence of this approach is that a secure channel to the registrar is required, and the same issues as discussed in draft-ietf-sip-identity must be addressed. Section 13.3 of Identity, Securing the Connection to the Authentication Service, brings up the important point that while direct TLS connections are preferred, they are not feasible in all architectures. For requests, mechanism such as auth-int can be used to add some protection, and the identity service can always challenge a request before adding an Identity header. There is no mechanism for challenging responses, so the proposed mechanism can only be used when a UAC has SIPS level of trust its DAS response identity provider. * using AIBs with hidden identity seems to require that the uac attempt to fetch a certs for every entry in the via path. It could take a long time for this to complete, and while sip-certs could be used for this it is currently scoped to UA certificates; I don't think it includes proxy certificates. It also requires that FQDN entries be placed in via headers. If only element has a resolvable source for certificates in the via path its desire to remain anonymous will be compromised. * Response-Authorization and Response-Authentication are defined in the draft but not used Thanks, Derek ------=_NextPart_000_0009_01C64CBD.C7CEB320 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Feng,

 

There are some interesting approaches in this draft. = The main issue still seems to be how a proxy(response identity service) = trusts a response enough to sign it. A few specific = comments:

 

* for DAS how does a proxy trust a given response = enough to sign it? One straw-man approach is:

 

 To use DAS, a UAS must register over a secure channel.  The proxy

 will authenticate the user using digest = challenge and a shared secret.

 For TLS, only one identity will be allowed per = TLS session.  Only when

 these requirments are met can a proxy provide responder identity using

 DAS.  This is similar to how a proxy can = claim SIPS for an aor even if

 the UA in question does not have a = certificate. 

 

One consequence of this approach is that a secure = channel to the registrar is required, and the same issues as discussed in draft-ietf-sip-identity must be addressed.  Section 13.3 of = Identity, Securing the Connection to the Authentication Service, brings up the = important point that while direct TLS connections are preferred, they are not = feasible in all architectures. For requests, mechanism such as auth-int can be used = to add some protection, and the identity service can always challenge a request = before adding an Identity header. There is no mechanism for challenging = responses, so the proposed mechanism can only be used when a UAC has SIPS level of = trust its DAS response identity provider.   =

 

* using AIBs with hidden identity seems to require = that the uac attempt to fetch a certs for every entry in the via path. It could = take a long time for this to complete, and while sip-certs could be used for = this it is currently scoped to UA certificates; I don't think it includes proxy certificates.  It also requires that FQDN entries be placed in via headers.  If only element has a resolvable source for certificates = in the via path its desire to remain anonymous  will be = compromised.

   

* Response-Authorization and Response-Authentication = are defined in the draft but not used

 

Thanks,

 

Derek

------=_NextPart_000_0009_01C64CBD.C7CEB320-- --===============0490894793== 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 --===============0490894793==-- From sip-bounces@ietf.org Tue Mar 21 11:20:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjZU-00025q-9F; Tue, 21 Mar 2006 11:19:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjZS-00025c-CY for sip@ietf.org; Tue, 21 Mar 2006 11:18:58 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjZR-0005wF-3H for sip@ietf.org; Tue, 21 Mar 2006 11:18:58 -0500 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 <0IWH00HLPJU9JV@usaga01-in.huawei.com> for sip@ietf.org; Tue, 21 Mar 2006 08:15:46 -0800 (PST) Received: from jys3105061835 (DHCP-Wireless-131-204.ietf65.org [130.129.131.204]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWH0013HJU3J9@usaga01-in.huawei.com> for sip@ietf.org; Tue, 21 Mar 2006 08:15:45 -0800 (PST) Date: Tue, 21 Mar 2006 10:18:37 +0800 From: Xiao Wang Subject: Re: [Sip] Presence RLS To: Preeti agarwal Message-id: <017a01c64c8d$c84654f0$cc838182@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 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <018d01c63816$63923500$b2b04c0a@china.huawei.com> <441FABEB.8090901@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 use sip & sips URI, like "sip:uri@domain.com", not uri@domain.com Xiao ----- Original Message ----- From: "Preeti agarwal" To: Sent: Tuesday, March 21, 2006 3:31 PM Subject: [Sip] Presence RLS > Hi All, > > This is regarding Presence RLS . > 1. When creating Resource list document, the service uri for the > resource list would be with "sip:uri@domain.com" or "uri@domain.com" ? > 2. The entry URI for the same should be with "sip:presentity@domain.com" > or without sip: i.e "presentity@domain.com" > > I am referring draft-ietf-simple-xcap-08, where it has user sip: for both. > Would like to know whether sip: is mandatory in both the cases. > > Thanks, > Priti > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 21 11:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjod-000289-3H; Tue, 21 Mar 2006 11:34:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjob-0001eh-Er for sip@ietf.org; Tue, 21 Mar 2006 11:34:37 -0500 Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjnn-0006RH-6r for sip@ietf.org; Tue, 21 Mar 2006 11:33:50 -0500 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id k2LGQGwr007567; Tue, 21 Mar 2006 21:56:17 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k2LGY3a20095; Tue, 21 Mar 2006 22:04:03 +0530 (IST) Importance: Normal X-Priority: 3 (Normal) Subject: Re: [Sip] Presence RLS MIME-Version: 1.0 From: Rayees Khan To: Preeti agarwal Date: Tue, 21 Mar 2006 22:02:58 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 03/21/2006 10:02:58 PM, Serialize complete at 03/21/2006 10:02:58 PM, Itemize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 03/21/2006 10:02:58 PM, Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 21/03/2006 10:02:59 PM, Serialize complete at 21/03/2006 10:02:59 PM MIME-Version: 1.0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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="===============0514431350==" Errors-To: sip-bounces@ietf.org --===============0514431350== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

I think that the prepen can be anything ranging from sip:, sips: t= el: etc to even http: in case of XCAP.


regards
Rayees

=
-----Preeti agarwal <q16972@motorola.c= om> wrote: -----

To: sip@ietf.org
From: Preeti agarwal <q16972@moto= rola.com>
Date: 03/21/2006 07:31AM
Subject: [Sip] Presence RLS
=
Hi All,

This is regarding Pr= esence RLS .
1. When creating Resource list document, the service uri fo= r the
resource list would be with "sip:uri@domain.com" or "uri@domain.c= om" ?
2. The entry URI for the same should be with "sip:presentity@domai= n.com"
or without sip: i.e "presentity@domain.com"

I am referrin= g  draft-ietf-simple-xcap-08, where it has user sip: for both.
Woul= d like to know whether sip: is mandatory in both the cases.

Thanks,<= br>Priti


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


**= ***FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronic= s Software Systems Limited (FSS) and is intended solely for the use of the = individual to whom it is addressed. It may contain privileged or confident= ial information and should not be circulated or used for any purpose other = than for what it is intended. If you have received this message in error= 4; please notify the originator immediately. If you are not the intended re= cipient, you are notified that you are strictly prohibited from using&#= 44; copying, altering, or disclosing the contents of this message. = FSS accepts no responsibility for loss or damage arising from the use of th= e information transmitted by this email including damage from virus."
= --===============0514431350== 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 --===============0514431350==-- From sip-bounces@ietf.org Tue Mar 21 11:44:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjwO-00074x-Tn; Tue, 21 Mar 2006 11:42:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjwN-00074d-4f for sip@ietf.org; Tue, 21 Mar 2006 11:42:39 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjwM-0006zc-OS for sip@ietf.org; Tue, 21 Mar 2006 11:42:39 -0500 Received: from [130.129.131.95] (DHCP-Wireless-131-95.ietf65.org [130.129.131.95]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2LGh5j9006560 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 21 Mar 2006 10:43:07 -0600 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F02165F19@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F02165F19@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <579EB9CC-C2FA-4703-A98A-79819AB699B3@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] The Problem with PRACK Date: Tue, 21 Mar 2006 10:42:44 -0600 To: "" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: sip@ietf.org, adam@nostrum.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 They're in the proceedings: I think this is the URL http://www3.ietf.org/proceedings/05nov/slides/sipping-16/sld1.htm -- Dean On Mar 20, 2006, at 3:55 AM, wrote: > > Hello, > >> In Vancouver, Rohan put up a slide to demonstrate this issue >> graphically, but its impact hasn't been shared on the list. To >> that end, >> I'll point out that implementing the offer/answer procedures with >> PRACK >> requires a state machine with at least 52 states and 329 transitions. >> That's a *lot* of code, and the chances of getting it all right are >> pretty close to zero. > > If that is the case, I would really ask that slide with explanations > to be published in SIP mailing list. For instance I was not attending > Vancouver meeting, so I am currently lacking this piece of > information. > I would especially like to be explained where this multitude of states > and transitions come from for sending offers/answers in PRACK, > especially > when compared to a solution where those could only be sent in UPDATE. > > My point is that only after understanding all that it would be > possible > to evaluate the effectivity of proposed simplifying solutions like the > one Rohan has suggested. > >>> I went back over the 102 messages in this thread and did not hear >>> any > >>> comments on my concrete proposals: >>> : >>> comments on *this*? >> >> Out of curiosity, did you go through the exercise of putting together > an >> offer/answer state machine that takes this change into account? Is it >> much simpler? > > In my understanding, for 3GPP the following three proposals would > be OK: > >>> - require RSeq to start at 1 >>> - only acknowledge the most recent provisional. if the UAS wants to >>> send as new provisional that completely replaces a previous one it > can >>> send immediately. if the UAS wants to send a new provisional but >>> wants acknowledgement of a previous one, it has to wait for the > PRACK. >>> - send a provisional every 1 minute whether reliable or not. > (instead >>> of every one minute for unreliable and every 2.5 minutes for > reliable) > > but this last one would cause severe problems: > >>> - deprecate *offers* in PRACK (answers are still OK) > > I hope that we would be able to study the problem closer in order to > find out if there still be some other kind of simplifications to be > made, to get the state machinery smaller, while keeping the > possibility > of sending offers in PRACK. Full analysis is still to be done, but it > would require the referred state machine to be scrutinized. > > Regards, > > Erkki > >> -----Original Message----- >> From: ext Adam Roach [mailto:adam@nostrum.com] >> Sent: 18.March.2006 02:58 >> To: Drage, Keith (Keith) >> Cc: sip@ietf.org >> Subject: Re: [Sip] The Problem with PRACK >> >> Drage, Keith (Keith) wrote: >> >>> If PRACK is bad, and I have not yet seen any technical >> evidence provided against it except that potentially it is >> hard to implement right... >>> >> >> You miss the point. Calling PRACK "potentially hard to implement >> right" >> is like referring to WWII as "a trifling difference of opinions." >> >> In Vancouver, Rohan put up a slide to demonstrate this issue >> graphically, but its impact hasn't been shared on the list. To >> that end, >> I'll point out that implementing the offer/answer procedures with >> PRACK >> requires a state machine with at least 52 states and 329 transitions. >> That's a *lot* of code, and the chances of getting it all right are >> pretty close to zero. >> >> All of which makes me very skeptical of arguments that we can't >> change >> PRACK because it has been widely implemented: I offer that it's >> highly >> unlikely that it has been implemented correctly even once. >> >> /a >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 21 11:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLk2D-0002ga-W5; Tue, 21 Mar 2006 11:48:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLk2C-0002gV-Bm for sip@ietf.org; Tue, 21 Mar 2006 11:48:40 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLk2B-0007Jd-1R for sip@ietf.org; Tue, 21 Mar 2006 11:48:40 -0500 Received: from [130.129.131.95] (DHCP-Wireless-131-95.ietf65.org [130.129.131.95]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2LGn6pX006577 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 21 Mar 2006 10:49:07 -0600 In-Reply-To: <20060320193838.42443.qmail@web8906.mail.in.yahoo.com> References: <20060320193838.42443.qmail@web8906.mail.in.yahoo.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36ED26BA-5589-4F4E-91C4-A574CC7975E8@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Comment on sip-tls-use draft Date: Tue, 21 Mar 2006 10:48:45 -0600 To: Thejeswara Reddy X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, vkg@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 On Mar 20, 2006, at 1:38 PM, Thejeswara Reddy wrote: > HI, > > Is it possible to convert sips (tls) to TCP (as proxy > does from UDP to TCP), if the UAS wont support TLS, and the call is > emrgency............ (dont want drop the call because of sips uri) > Yes, RFC 3261 specifically allows for the UAC to AOR-PROXY link to be SIPS, and the AOR-PROXY to UAS link to be SIP. You've just described one of the motivating use cases. This is controversial. Some people think that it should be changed so that TLS MUST be used all the way through. The problem with this suggestion (in addition to breaking your use case) is that, with the current protocol design, this requirement is "toothless"./ There's no way for the UAC to know whether or not the TLS requirement was honored. Therefore, we must assume it wasn't. Proposals for fixing this are circulating. -- 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 Mar 21 12:14:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkOt-00025g-QY; Tue, 21 Mar 2006 12:12:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkOs-00025W-RU for sip@ietf.org; Tue, 21 Mar 2006 12:12:06 -0500 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkOs-0008TX-8y for sip@ietf.org; Tue, 21 Mar 2006 12:12:06 -0500 thread-index: AcZNCpvDFoqMYH6gQGSj+JXHKUL/Qg== Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 18:12:18 +0100 Received: from PTPXCH029BA020.idc.cww.telecomitalia.it ([156.54.240.46]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 18:12:05 +0100 Received: from [163.162.113.137] ([163.162.113.137]) by PTPXCH029BA020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 18:12:03 +0100 Message-ID: <44203439.60107@telecomitalia.it> Date: Tue, 21 Mar 2006 11:13:29 -0600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-Class: urn:content-classes:message Importance: normal Priority: normal From: "Enrico Marocco" User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Adam Roach" Subject: Re: [Sip] The Problem with PRACK References: <072C5B76F7CEAB488172C6F64B30B5E3013D7D20@xmb-rtp-20b.amer.cisco.com> <441ECB93.1040008@estacado.net> In-Reply-To: <441ECB93.1040008@estacado.net> X-OriginalArrivalTime: 21 Mar 2006 17:12:04.0215 (UTC) FILETIME=[9340D870:01C64D0A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: sip@ietf.org, jh@tutpro.com, Alberto Cuda , christer.holmberg@ericsson.com, drage@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: , Content-Type: multipart/mixed; boundary="===============1486573239==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1486573239== Content-Type: multipart/alternative; boundary="----=_NextPart_000_BA28F_01C64D12.FD8771A0" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_BA28F_01C64D12.FD8771A0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A couple of mounts age we have submitted an informational draft=20 (draft-cuda-sipping-ua-fsm-00) describing an alternative and hopefully=20 more intuitive formal model for representing the full negotiation. The=20 effort of that draft was on separating and showing relations between the = three state machine involved in the process (session, media negotiation=20 and signalling). Maybe it could be somewhat userful in this analysis. Enrico Adam Roach wrote: > Michael Hammer (mhammer) wrote: >=20 >> Anyway, I haven't seen the 50+ state diagram from Vancouver either, = but >> it would be good to have that distributed on the mail list. I must = have >> missed that one if it was. >> =20 >> > Because the graphic doesn't work well on a mailing list, I've put it=20 > here in text format. If you want the visual impact of the graph that=20 > Rohan put up at IETF64, grab the PDF file at=20 > = http://scm.sipfoundry.org/viewsvn/*checkout*/resiprocate/main/resip/dum/d= oc/dum-fsms1.pdf=20 >=20 >=20 > This comes from the Dialog Usage Manager in the resiprocate stack; the = > transition is denoted as "oldstate->newstate"; the trigger and=20 > subsequent actions are indicated following that line. [sorry, dropped for honouring 40K size limit] -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_BA28F_01C64D12.FD8771A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
A couple of mounts = age we have submitted an informational draft =
(draft-cuda-sipping-ua-fsm-00) describing an alternative and = hopefully
more intuitive formal model for representing the full = negotiation. The
effort of that draft was on separating and showing = relations between the
three state machine involved in the process = (session, media negotiation
and signalling).

Maybe it could = be somewhat userful in this analysis.

Enrico

Adam Roach = wrote:
> Michael Hammer (mhammer) wrote:
>
>> Anyway, I = haven't seen the 50+ state diagram from Vancouver either, but
>> it = would be good to have that distributed on the mail list. I must = have
>> missed that one if it was.
>>
>>
> Because the = graphic doesn't work well on a mailing list, I've put it
> here in = text format. If you want the visual impact of the graph that
> Rohan = put up at IETF64, grab the PDF file at
> = http://scm.sipfoundry.org/viewsvn/*checkout*/resiprocate/main/resip/dum/d= oc/dum-fsms1.pdf
>
>
> This comes from the Dialog Usage = Manager in the resiprocate stack; the
> transition is denoted as = "oldstate->newstate"; the trigger and
> subsequent actions are = indicated following that line.

[sorry, dropped for honouring 40K = size limit]
--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_BA28F_01C64D12.FD8771A0-- --===============1486573239== 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 --===============1486573239==-- From sip-bounces@ietf.org Tue Mar 21 13:13:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlK9-0007U2-0t; Tue, 21 Mar 2006 13:11:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlK7-0007Tx-9V for sip@ietf.org; Tue, 21 Mar 2006 13:11:15 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLlK6-0002f2-30 for sip@ietf.org; Tue, 21 Mar 2006 13:11:15 -0500 Received: from ITLOANER (DHCP-Wired-67-216.ietf65.org [130.129.67.216]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k2LIB8Qh015964; Tue, 21 Mar 2006 13:11:12 -0500 (EST) Message-Id: <200603211811.k2LIB8Qh015964@bdsoft10.vwh.net> From: "Brett Tate" To: "'Jonathan Rosenberg'" , "'IETF SIP List'" Subject: RE: [Sip] comments on sip-connected-identity Date: Tue, 21 Mar 2006 12:11:01 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <442011A8.4020008@cisco.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZM9llF/E1cRBw1SI2qA7tX/Wf5AAAFe/5Q X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 > Secondly, on the issue of UPDATE without offers, I believe it is > fine to do this. Though not in RFC3311, this was part of the > original conceived use of UPDATE > (see http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt). > We decided towards the end of the development to focus on the > session update aspects of this. However, I think its fine to > use UPDATE in this fashion, as long as the peer in the dialog > indicates support for this usage of UPDATE (through > the dialogURIChange tag). Jonathan, I was surprised to hear you indicating that RFC3311 doesn't allow update without sdp. Where is it indicated within RFC3311 that update must contain an offer? RFC3311 section 5.1 implies that update can be sent without an offer by clearly indicating that it can't contain an offer within some situations. And section 5.2 implies the same thing by discussing receiving an update containing an offer. And if bodies are mandatory for update, why does table 1 indicate * instead of m for content-type? When update without sdp was discussed for usage within RFC4028, requiring uas to support timer was never suggested or mentioned. And such a requirement is not mentioned within RFC4028. Thanks, Brett _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 21 14:52:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLmrz-0004QF-Ue; Tue, 21 Mar 2006 14:50:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLmry-0004Q6-DO for sip@ietf.org; Tue, 21 Mar 2006 14:50:18 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLmrw-0005y3-T7 for sip@ietf.org; Tue, 21 Mar 2006 14:50:18 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWH007TRU9JFI@szxga01-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 04:00:55 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWH005X8U9I2U@szxga01-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 04:00:55 +0800 (CST) Received: from jys3105061846 (DHCP-Wireless-133-214.ietf65.org [130.129.133.214]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWH00D7PUJ03M@szxml01-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 04:06:50 +0800 (CST) Date: Tue, 21 Mar 2006 13:49:46 -0600 From: Rocky Wang To: sip@ietf.org Message-id: <000001c64d20$a1a25360$d6858182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZNIJq3hvEHZb4hRyiowH8VHfSIEA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip-connected-identity-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 Both of draft-cao-sip-response-identity-00 and draft-elwell-sip-connected-identity-01 have been disscussed in today's SIP session. I found they two can be merged into one. The first one is a common requirement to return back the identity identifier. It can be used in both successful responses, but also in provisiional, redirect and failure responses, but the 2nd one is just used for 18X and 2XX response for INVITE (maybe also some other type requests). As I considered, the 2nd one is just a sub-set case of the first one. Can merge the 2nd one into the 1st one? Or merge the requirement of the 1st into the last. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 21 16:07:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLo2X-0005XB-SD; Tue, 21 Mar 2006 16:05:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLntZ-0000TL-PD for sip@ietf.org; Tue, 21 Mar 2006 15:56:02 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLntX-0001ZS-KT for sip@ietf.org; Tue, 21 Mar 2006 15:56:00 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2LKtu9c046089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 14:55:59 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4420685B.3080804@nostrum.com> Date: Tue, 21 Mar 2006 14:55:55 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] RFC3261: Errata? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org During today's SIP meeting, someone (I think it was Vijay) raised an issue around being able to point to some place that provides clarifications and corrections for RFC3261. In looking at the errata page for RFC 3261: http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=3261& I notice that there's only one correction there, and it's relatively pedantic (as opposed to fixing a fundamental problem that will cause interoperability issues). To address the issue raised in SIP about where to point people about these clarifications and fixes, it seems to me that it might make sense to take some subset of the known flaws and submit them as errata. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 21 16:39:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLoY0-0000TN-3K; Tue, 21 Mar 2006 16:37:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLoXz-0000T8-4Z for sip@ietf.org; Tue, 21 Mar 2006 16:37:47 -0500 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 1FLoXx-0004IK-QB for sip@ietf.org; Tue, 21 Mar 2006 16:37:47 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2006 13:37:45 -0800 X-IronPort-AV: i="4.03,116,1141632000"; d="scan'208"; a="419019118:sNHT25050120" 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 k2LLbjw1028857; Tue, 21 Mar 2006 13:37:45 -0800 (PST) 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.211); Tue, 21 Mar 2006 13:37:45 -0800 Received: from [130.129.128.208] ([10.89.16.127]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 13:37:44 -0800 Message-ID: <44207227.20907@cisco.com> Date: Tue, 21 Mar 2006 16:37:43 -0500 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: Adam Roach Subject: Re: [Sip] RFC3261: Errata? References: <4420685B.3080804@nostrum.com> In-Reply-To: <4420685B.3080804@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2006 21:37:44.0937 (UTC) FILETIME=[B0A9FD90:01C64D2F] 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 I think thats just more confusing; it would mean that there are two places to go to for errata, and we need to keep them in sync. I'd prefer to stick with bugzilla as the primary source. -Jonathan R. Adam Roach wrote: > During today's SIP meeting, someone (I think it was Vijay) raised an > issue around being able to point to some place that provides > clarifications and corrections for RFC3261. In looking at the errata > page for RFC 3261: > > http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=3261& > > I notice that there's only one correction there, and it's relatively > pedantic (as opposed to fixing a fundamental problem that will cause > interoperability issues). > > To address the issue raised in SIP about where to point people about > these clarifications and fixes, it seems to me that it might make sense > to take some subset of the known flaws and submit them as errata. > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- 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 Mar 21 16:55:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLonK-00038y-Lv; Tue, 21 Mar 2006 16:53:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLonJ-00037h-ED for sip@ietf.org; Tue, 21 Mar 2006 16:53:37 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLonI-00051A-6S for sip@ietf.org; Tue, 21 Mar 2006 16:53:37 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2LLrYid004632; Tue, 21 Mar 2006 15:53:34 -0600 (CST) Received: from [135.244.9.75] (vkg.lra2.lucent.com [135.244.9.75]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2LLrXt07195; Tue, 21 Mar 2006 15:53:33 -0600 (CST) Message-ID: <442075DD.3050209@lucent.com> Date: Tue, 21 Mar 2006 15:53:33 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] RFC3261: Errata? References: <4420685B.3080804@nostrum.com> <44207227.20907@cisco.com> In-Reply-To: <44207227.20907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org, Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > I think thats just more confusing; it would mean that there are two > places to go to for errata, and we need to keep them in sync. I'd prefer > to stick with bugzilla as the primary source. I don't really care if we store clarifications and corrections as a list of errata, or in bugzilla as long as whatever it is, it is updated regularly and serves as a one-stop shop for all the known issues in the protocol. For instance, the invaluable reports that RjS sends out to the SIP* WG lists after bakeoffs should be archived someplace accessible by a single link. Searching for it in the IETF archives is really time consuming unless you know the date or subject of the posting for a targetted google search. 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 Tue Mar 21 18:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpw1-0003vq-89; Tue, 21 Mar 2006 18:06:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpvz-0003vf-7b for sip@ietf.org; Tue, 21 Mar 2006 18:06:39 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpvy-00007L-RM for sip@ietf.org; Tue, 21 Mar 2006 18:06:39 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id k2LN6aws016125; Tue, 21 Mar 2006 16:06:36 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on location conveyance draft Date: Tue, 21 Mar 2006 16:06:36 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZL8H4R86DD5YbOR8u/Me03TiHeAQBNJMwg From: "Jean-Francois Mule" To: "James M. Polk" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 James and Brian, Here is a follow-up on SIP location conveyance draft and one of the open issues we discussed in the meeting. It relates to moving the requirements to an annex and expand on one of Jonathan's comment. To recap what I stated at the mike, section 3 of draft02 contains both design requirements (ones you used to craft the location conveyance solution), and, compliance or implementation requirements (requirements applicable to SIP entities implementing the RFC-to-be). The former set could be deleted, moved into an annex or put in a Specific section outlining the requirements that lead to the=20 solution. Some of the compliance requirements should remain in the core document imo to guide implementers and help interop. Here is a first cut at the dichotomy. If you find this is helpful and folks agree with the approach, I'd be willing to continue or propose new text. Jean-Francois. jfm@cablelabs.com --- re: draft-ietf-sip-location-conveyance-02.txt, in >3. Requirements for SIP Location Conveyance > > The following subsections address the requirements placed on > the user agent client, the user agent server, as well as SIP=20 > proxies when conveying location. > UAC-1 The SIP INVITE Method [RFC3261] MUST support Location=20 > Conveyance. category: design requirement; met by the proposed solution in I-D proposal: move to annex or simply remove. > > UAC-2 The SIP MESSAGE method [RFC3428] MUST support Location=20 > Conveyance. category: design requirement; met by the proposed solution in I-D proposal: move to annex or simply remove. > > UAC-3 SIP Requests within a dialog SHOULD support Location=20 > Conveyance. category: compliance requirement?; partially met by the proposed solution in the I-D since the location header is not allowed in ACK and CANCEL requests. proposal: reword to capture the table in section 4.1, here is a basic example with poor wording: [To claim compliance with this document,] a UAC MUST be capable of supporting Location Conveyance in SIP Requests within a dialog as indicated in table xxx. > UAC-4 Other SIP Requests MAY support Location Conveyance. category: design requirement.=20 Not met by the solution since ACK and CAN are marked "-". Indeed, per RFC 3261 section 19.1.1., entries marked "m" are mandatory, those marked "o" are optional, and those marked=20 "-" are not allowed. proposal: move to annex or simply remove. If you agree with the reword above, you also fold this design requirement. > UAC-5 There MUST be one, mandatory to implement means of=20 > transmitting location confidentially. category: design requirement.=20 proposal: remove or reword (i don't understand the requirement here). note: starting a 2119 requirement by words like "there" or "it" is usually a sign that it should be reworded.=20 > Motivation: interoperability=20 > > UAC-6 It MUST be possible for a UAC to update location conveyed=20 > prior to dialog establishment. > Motivation: in case a UAC has moved prior to the establishment of a=20 > dialog between UAs, the UAC must be able to send new location > information. category: compliance or design requirement? proposal: reword to inject the clearer motivation text in the actual requirement. Not sure whether the requirement is on a UAC to be "able" to send new location or the UAS to be capable of receiving and processing location updates. > UAC-7 The privacy and security rules established within [RFC3693]=20 > that would categorize SIP as a 'using protocol' MUST be met. > See Section 7 for analysis. category: design requirement as written proposal: delete as it is addressed in section 7 (also does not only belong to UAC). =20 > UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for=20 > location conveyance within SIP, whether included by-value or=20 > by-reference. category: design requirement as written proposal: reword to capture the UAC requirement, for e.g.,=20 a UAC MUST support/comply with/implement the PIDF-LO=20 location format defined in [RFC4119] as a PIDF-LO.=20 > > Motivation: interoperability=20 note: Especially for interoperability, it would be a plus to also indicate the level of requirement for PIDF-LO "by-value" or "by-value" (is one of them a MUST, are both SHOULD to comply with the SIP Location conveyance RFC)? If this is specified elsewhere, mention it and add a pointer. > UAC-9 A UAC MUST be capable of transmitting a SIP request without=20 > protecting the PIDF-LO message body. It is RECOMMENDED this=20 > not be the default configuration of any UA. This requirement > is orthogonal to the use of TLS or IPSec hop-by-hop between=20 > SIP elements. category: compliance requirement proposal: clarify requirement: how or when does a UAC decide to not "protect" the PIDF-LO msg body part?=20 from a pure requirement point of view, I think you want a MUST for UAC to be capable of protecting the msg body part, *and*, a MAY for the UAC to be able to transmit without it (in some circumstances). > Motivation: If a SIP request is part of an emergency call,=20 > therefore includes the UAC's location, the UAC may understand > through local policy or configuration that a proxy server=20 > will need to learn the UAC's location to route the message=20 > correctly. Using S/MIME on the PIDF-LO defeats this=20 > capability in proxies. note: some of the motivation text should be injected in the requirement. I would recommend getting rid of the "motivation" sub-paragraphs in favor of improved requirement text. > UAC-10 A UAC MUST allow its user to be able to disable providing=20 > location within any SIP request message. It is RECOMMENDED=20 > this not be the default configuration of any UA. =20 category: compliance requirement? should this be informative as this is based on "local laws"? or is this a hard requirement that UACs compliant to this SIP location conveyance RFC have to do? proposal: reword to integrate the motivation below. > > Motivation: local laws may give this right to all users within a=20 > jurisdiction, even when the request is initiating an=20 > emergency call. if this walk through is helpful, I can volunteer to continue or just propose new 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 Tue Mar 21 18:19:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLq6G-0000NF-1i; Tue, 21 Mar 2006 18:17:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLq6F-0000NA-19 for sip@ietf.org; Tue, 21 Mar 2006 18:17:15 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLq6D-0000M3-PR for sip@ietf.org; Tue, 21 Mar 2006 18:17:15 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2LNHC54054018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 17:17:12 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44208976.50800@nostrum.com> Date: Tue, 21 Mar 2006 17:17:10 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] RFC3261: Errata? References: <4420685B.3080804@nostrum.com> <44207227.20907@cisco.com> In-Reply-To: <44207227.20907@cisco.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org, Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > I think thats just more confusing; it would mean that there are two > places to go to for errata, and we need to keep them in sync. I'd > prefer to stick with bugzilla as the primary source. I understand the sentiment. The issue is that there's this kind-of well known place (at least, for people who have a passing familiarity with the IETF) that people can go to find RFC errata. It's a bit hard to find for the uninitiated, but the fact that the mechanism is the same for some 4000+ documents gives it *some* visibility. On top of that, we add what looks to an outsider like our own uber-secret-handshake hidden repository of SIP errata, and I'm not sure how anyone is ever going to benefit from the collected SIPit knowledge until we publish 3261bis. Am I missing some kind of pointer that is likely to lead implementors, vendors, and operators to the bugzilla database? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 21 19:16:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqzd-0004E8-EC; Tue, 21 Mar 2006 19:14:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqzc-0004CR-CS for sip@ietf.org; Tue, 21 Mar 2006 19:14:28 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLqx0-00034q-31 for sip@ietf.org; Tue, 21 Mar 2006 19:11:47 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 21 Mar 2006 16:11:45 -0800 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 k2M0Bjw1018340; Tue, 21 Mar 2006 16:11:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 16:11:45 -0800 Received: from [130.129.128.208] ([10.89.16.64]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 16:11:43 -0800 Message-ID: <4420963E.9050607@cisco.com> Date: Tue, 21 Mar 2006 19:11:42 -0500 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: Adam Roach Subject: Re: [Sip] RFC3261: Errata? References: <4420685B.3080804@nostrum.com> <44207227.20907@cisco.com> <44208976.50800@nostrum.com> In-Reply-To: <44208976.50800@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2006 00:11:44.0265 (UTC) FILETIME=[33BB8F90:01C64D45] 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 We could ask the rfc-editor to link to the bugzilla site. -Jonathan R. Adam Roach wrote: > Jonathan Rosenberg wrote: > > >>I think thats just more confusing; it would mean that there are two >>places to go to for errata, and we need to keep them in sync. I'd >>prefer to stick with bugzilla as the primary source. > > > > I understand the sentiment. The issue is that there's this kind-of well > known place (at least, for people who have a passing familiarity with > the IETF) that people can go to find RFC errata. It's a bit hard to find > for the uninitiated, but the fact that the mechanism is the same for > some 4000+ documents gives it *some* visibility. > > On top of that, we add what looks to an outsider like our own > uber-secret-handshake hidden repository of SIP errata, and I'm not sure > how anyone is ever going to benefit from the collected SIPit knowledge > until we publish 3261bis. > > Am I missing some kind of pointer that is likely to lead implementors, > vendors, and operators to the bugzilla database? > > /a > -- 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 Mar 21 23:43:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLvAO-00044X-Eh; Tue, 21 Mar 2006 23:41:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLvAM-00044S-Fg for sip@ietf.org; Tue, 21 Mar 2006 23:41:50 -0500 Received: from [219.141.250.5] (helo=mail) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLvAK-0004Bw-ST for sip@ietf.org; Tue, 21 Mar 2006 23:41:50 -0500 Received: from asechenshuping (ase_chenshuping.cecwireless.com.cn [10.2.4.92]) by mail.cecwireless.com.cn (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTPA id <0IWI00KA2IC98F@mail.cecwireless.com.cn> for sip@ietf.org; Wed, 22 Mar 2006 12:41:07 +0800 (CST) Date: Wed, 22 Mar 2006 12:41:33 +0800 From: Chen Shuping To: sip@ietf.org Message-id: <006001c64d6a$e5aadc90$5c04020a@cecwireless.com.cn> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZNauSXfQqqHLgYQzypJ3GiENYd9w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Sip] [simple] How to get PIDF schema file X-BeenThere: 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="===============0493086615==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0493086615== Content-type: multipart/alternative; boundary="Boundary_(ID_VYP6vwpNP1uI3rtAcQIJuw)" This is a multi-part message in MIME format. --Boundary_(ID_VYP6vwpNP1uI3rtAcQIJuw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi,All I am now working on presence software,I want to know where I can get presence schema file.Thanks. --Boundary_(ID_VYP6vwpNP1uI3rtAcQIJuw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi,All
 
 
     I am now working on presence software,I want to know
 
where I can get presence schema file.Thanks.
--Boundary_(ID_VYP6vwpNP1uI3rtAcQIJuw)-- --===============0493086615== 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 --===============0493086615==-- From sip-bounces@ietf.org Wed Mar 22 00:46:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLw9F-0001Q3-V4; Wed, 22 Mar 2006 00:44:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLw9E-0001Nz-HY for sip@ietf.org; Wed, 22 Mar 2006 00:44:44 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLw9D-0006i7-5K for sip@ietf.org; Wed, 22 Mar 2006 00:44:44 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWI00101L5U09@siemenscomms.co.uk> for sip@ietf.org; Wed, 22 Mar 2006 05:41:54 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWI00H85L5UJ6@siemenscomms.co.uk>; Wed, 22 Mar 2006 05:41:54 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Mar 2006 05:44:41 +0000 Content-return: allowed Date: Wed, 22 Mar 2006 05:44:01 +0000 From: "Elwell, John" Subject: RE: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 To: Rocky Wang , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708755F06@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 1.1 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Rocky, The connected-identity draft is not a subset of the response identity draft. The response identity draft cannot be used to indicate a change of party mid-dialog. I don't think we can merge them. There was no consensus on the response identity draft. The following views have been expressed: - that it does not provide any benefit; - that the response identity problem cannot be solved, and that the approach taken in the connected-identity draft is the best that can be achieved. If and when there is consensus on a response identity solution, then we could consider whether it would be appropriate to merge the two, but that is not the case at present. John > -----Original Message----- > From: Rocky Wang [mailto:rocky.wang@huawei.com] > Sent: 21 March 2006 19:50 > To: sip@ietf.org > Subject: [Sip] draft-cao-sip-response-identity-00 and > draft-elwell-sip-connected-identity-01 > > > Both of draft-cao-sip-response-identity-00 and > draft-elwell-sip-connected-identity-01 have been disscussed > in today's SIP > session. I found they two can be merged into one. > The first one is a common requirement to return back the identity > identifier. It can be used in both successful responses, but also in > provisiional, redirect and failure responses, but the 2nd one > is just used > for 18X and 2XX response for INVITE (maybe also some other > type requests). > As I considered, the 2nd one is just a sub-set case of the > first one. Can > merge the 2nd one into the 1st one? Or merge the requirement > of the 1st into > the last. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 02:00:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLxIw-0000XL-62; Wed, 22 Mar 2006 01:58:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLxIv-0000TK-6u for sip@ietf.org; Wed, 22 Mar 2006 01:58:49 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLxIs-0000yo-HA for sip@ietf.org; Wed, 22 Mar 2006 01:58:49 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0F2C24F0002; Wed, 22 Mar 2006 07:57:17 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 07:57:16 +0100 Received: from [136.225.183.112] ([136.225.183.112]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 07:57:13 +0100 From: "Christer Holmberg" To: "Brett Tate" , "'Jonathan Rosenberg'" , "'IETF SIP List'" Subject: RE: [Sip] comments on sip-connected-identity Date: Wed, 22 Mar 2006 08:52:21 +0200 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 22 Mar 2006 06:57:16.0484 (UTC) FILETIME=[DADD8840:01C64D7D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Didn't the update-without-sdp come uo a while ago, when we discussed = sessions without media etc? If one simply wants to update the remote target, using uodate, why would it = be required to include a body? 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 Mar 22 06:38:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM1e0-0000ea-7V; Wed, 22 Mar 2006 06:36:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM1dz-0000eV-1s for sip@ietf.org; Wed, 22 Mar 2006 06:36:51 -0500 Received: from zproxy.gmail.com ([64.233.162.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM1dw-00035v-QI for sip@ietf.org; Wed, 22 Mar 2006 06:36:51 -0500 Received: by zproxy.gmail.com with SMTP id x3so50278nzd for ; Wed, 22 Mar 2006 03:36:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:from:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=Q6rAUGRwfC+Sph9SUYgCe66RhiKE4pE9+P5BORXrnJWXSQ50qwpAQ75sDIvBDlsLuaD2CBwddC+gVrKlKv37A5GOxwBrJESoiIknysSJMVS1IWtCYDam7piNIbCoTl6Ec3pNEK0DtvEEo7X0OIzCrQgV/zUGpGhlSIf1q51e8fY= Received: by 10.36.135.1 with SMTP id i1mr1129791nzd; Wed, 22 Mar 2006 03:36:47 -0800 (PST) Received: from leo ( [60.178.150.223]) by mx.gmail.com with ESMTP id 38sm592720nza.2006.03.22.03.36.46; Wed, 22 Mar 2006 03:36:47 -0800 (PST) Message-ID: <005d01c64da4$e6e5c130$1200a8c0@leo> From: "Leo" To: Date: Wed, 22 Mar 2006 19:36:43 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Sip] SIP RFC Lite X-BeenThere: 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="===============0878734298==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0878734298== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01C64DE7.F31FF5E0" This is a multi-part message in MIME format. ------=_NextPart_000_005A_01C64DE7.F31FF5E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpSRkMgTGl0ZSBpcyBKdXBob29uJ3MgaW50ZXJuYWwgcHJvamVjdCwgYWltaW5n IGF0IHNpbXBsaWZ5aW5nIFJGQ3MgYW5kIGhlbHBpbmcgcHJvZ3JhbW1lcnMgdG8gZm9jdXMgb24g c2lnbmlmaWNhbnQgY29uY2VwdHMgYW5kIHRoZSBsb2dpYyBkZXBpY3RlZCBpbiBSRkNzLiBJdCBo YXMgYmVlbiBwcm92ZWQgdGhhdCBSRkMgTGl0ZSBjYW4gaGVscCBwb2dyYW1tZXJzIHdobyBhcHBs eSB0aGVtc2VsdmVzIHRvIHByb3RvY29sIGRldmVsb3BtZW50IHRvIHVuZGVyc3RhbmQgdGhlIGVz c2VuY2Ugb2YgUkZDcyBmb3IgbGVzcyB0aW1lLg0KDQpOb3cgd2Ugc2hhcmUgc29tZSBSRkMgTGl0 ZXMsIGFuZCBtb3JlIFJGQ3Mgd2lsbCBiZSB1cGRhdGVzIGFuZCB1cGxvYWQuIEkgaG9wZSBpdCBt YXkgaGVscCB0byBTSVAgaW1wbGVtZW50b3JzLCBlc3BlY2lhbGx5IGZvciB0aG9zZSBTSVAgbmV3 IHVzZXJzLg0KDQpJZiBhbnlvbmUgaGFzIGludGVyZXN0aW5nIGluIGpvaW4gUkZDIGxpdGVzIHBy b2plY3QsIHBsZWFzZSBtYWlsIHRvIG1lKGxlby5sdkBqdXBob29uLmNvbSkuDQoNClRoZSB3ZWJz aXRlIGlzIA0KaHR0cDovL3d3dy5qdXBob29uLmNvbS9lbi9zdXBwb3J0L2Rvd25sb2FkcyZ1cGRh dGVzLmh0bQ0KDQpUaGFuayB5b3UuDQoNCkJlc3QgcmVnYXJkcyENCg0KTGVvIEx2DQo= ------=_NextPart_000_005A_01C64DE7.F31FF5E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI4MzgiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj4NCjxESVY+PEZPTlQgc2l6 ZT0yPg0KPERJVj48Rk9OVCBzaXplPTI+SGkgQWxsLDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5SRkMgTGl0ZSBpcyBKdXBob29uJ3MgaW50ZXJuYWwg cHJvamVjdCwgYWltaW5nIGF0IHNpbXBsaWZ5aW5nIA0KUkZDcyBhbmQgaGVscGluZyBwcm9ncmFt bWVycyB0byBmb2N1cyBvbiBzaWduaWZpY2FudCBjb25jZXB0cyBhbmQgdGhlIGxvZ2ljIA0KZGVw aWN0ZWQgaW4gUkZDcy4gSXQgaGFzIGJlZW4gcHJvdmVkIHRoYXQgUkZDIExpdGUgY2FuIGhlbHAg cG9ncmFtbWVycyB3aG8gYXBwbHkgDQp0aGVtc2VsdmVzIHRvIHByb3RvY29sIGRldmVsb3BtZW50 IHRvIHVuZGVyc3RhbmQgdGhlIGVzc2VuY2Ugb2YgUkZDcyBmb3IgbGVzcyANCnRpbWUuPC9GT05U PjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPk5vdyB3ZSBzaGFy ZSBzb21lIFJGQyBMaXRlcywgYW5kIG1vcmUgUkZDcyB3aWxsIGJlIHVwZGF0ZXMgYW5kIA0KdXBs b2FkLiBJIGhvcGUgaXQgbWF5IGhlbHAgdG8gU0lQIGltcGxlbWVudG9ycywgZXNwZWNpYWxseSBm b3IgdGhvc2UgU0lQIG5ldyANCnVzZXJzLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5JZiBhbnlvbmUgaGFzIGludGVyZXN0aW5nIGluIGpvaW4gUkZD IGxpdGVzIHByb2plY3QsIHBsZWFzZSANCm1haWwgdG8gbWUoPEEgDQpocmVmPSJtYWlsdG86bGVv Lmx2QGp1cGhvb24uY29tIj5sZW8ubHZAanVwaG9vbi5jb208L0E+KS48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5U aGUgd2Vic2l0ZSBpcyA8QlI+PEEgDQpocmVmPSJodHRwOi8vd3d3Lmp1cGhvb24uY29tL2VuL3N1 cHBvcnQvZG93bmxvYWRzJmFtcDt1cGRhdGVzLmh0bSI+aHR0cDovL3d3dy5qdXBob29uLmNvbS9l bi9zdXBwb3J0L2Rvd25sb2FkcyZhbXA7dXBkYXRlcy5odG08L0E+PC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoYW5rIHlvdS48L0ZPTlQ+PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QmVzdCByZWdhcmRzITwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPkxlbyANCkx2PEJSPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9GT05UPjwv RElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_005A_01C64DE7.F31FF5E0-- --===============0878734298== 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 --===============0878734298==-- From sip-bounces@ietf.org Wed Mar 22 10:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM4wC-0001rL-2Y; Wed, 22 Mar 2006 10:07:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM4wA-0001pI-CK for sip@ietf.org; Wed, 22 Mar 2006 10:07:50 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM4wA-0002ij-At for sip@ietf.org; Wed, 22 Mar 2006 10:07:50 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FM4sT-0003CK-He for sip@ietf.org; Wed, 22 Mar 2006 10:04:03 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ006D1BKTR4@szxga01-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 23:12:29 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ00D73BJRXW@szxga01-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 23:12:29 +0800 (CST) Received: from jys3105061846 (DHCP-Wireless-132-2.ietf65.org [130.129.132.2]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWJ00DLUB17VR@szxml01-in.huawei.com>; Wed, 22 Mar 2006 23:01:16 +0800 (CST) Date: Wed, 22 Mar 2006 08:43:52 -0600 From: Rocky Wang Subject: RE: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip-connected-identity-01 In-reply-to: <50B1CBA96870A34799A506B2313F266708755F06@ntht201e.siemenscomms.co.uk> To: "'Elwell, John'" , sip@ietf.org Message-id: <010201c64dbf$1d027370$d6858182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZNc8K3/wx9zSh5ROWckV0OmB/8LgASjoZQ X-Spam-Score: -1.3 (-) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 my opinion, they two just need take the responser identifier in the response messages. We must consider and resolve all the problem include the security problems in both cases. If you want to indicate a change of party mid-dialog, you can use some mid-dialog method to do it, as I considered, just like UPDATE and re-INVITE. That's not so difficult in use of exist mechanism. But can you please give me an application case of the usage of mid-dialog entity identifier indication. -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Tuesday, March 21, 2006 11:44 PM To: Rocky Wang; sip@ietf.org Subject: RE: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip-connected-identity-01 Rocky, The connected-identity draft is not a subset of the response identity draft. The response identity draft cannot be used to indicate a change of party mid-dialog. I don't think we can merge them. There was no consensus on the response identity draft. The following views have been expressed: - that it does not provide any benefit; - that the response identity problem cannot be solved, and that the approach taken in the connected-identity draft is the best that can be achieved. If and when there is consensus on a response identity solution, then we could consider whether it would be appropriate to merge the two, but that is not the case at present. John > -----Original Message----- > From: Rocky Wang [mailto:rocky.wang@huawei.com] > Sent: 21 March 2006 19:50 > To: sip@ietf.org > Subject: [Sip] draft-cao-sip-response-identity-00 and > draft-elwell-sip-connected-identity-01 > > > Both of draft-cao-sip-response-identity-00 and > draft-elwell-sip-connected-identity-01 have been disscussed in today's > SIP session. I found they two can be merged into one. > The first one is a common requirement to return back the identity > identifier. It can be used in both successful responses, but also in > provisiional, redirect and failure responses, but the 2nd one is just > used for 18X and 2XX response for INVITE (maybe also some other type > requests). > As I considered, the 2nd one is just a sub-set case of the first one. > Can merge the 2nd one into the 1st one? Or merge the requirement of > the 1st into the last. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 10:17:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53S-00079W-QW; Wed, 22 Mar 2006 10:15:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53Q-00079E-0i for sip@ietf.org; Wed, 22 Mar 2006 10:15:20 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM53O-00037P-3c for sip@ietf.org; Wed, 22 Mar 2006 10:15:19 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ00INHBZSAY@szxga03-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 23:21:28 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ0067IBY7CR@szxga03-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 23:21:28 +0800 (CST) Received: from jys3105061846 (DHCP-Wireless-132-2.ietf65.org [130.129.132.2]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWJ0033WBDS0Q@szxml02-in.huawei.com>; Wed, 22 Mar 2006 23:08:26 +0800 (CST) Date: Wed, 22 Mar 2006 08:55:09 -0600 From: Rocky Wang To: rohan@ekabal.com, brett@broadsoft.com Message-id: <010301c64dc0$9f782ab0$d6858182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZNwJz2mRAFyW5lSAaaJh57la1/Jg== X-Spam-Score: 1.6 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org 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: , Errors-To: sip-bounces@ietf.org Hi, Rohan and Brett, Why should we limit only one TLS connection between two entities? Suppose there are a huge traffic between proxys or proxy and application server, one TLS maybe will limit the traffic and application. I think they can keep and select a TLS connection if there are some, for example, load balance. And we should not mandate that the entities MUST NOT disconnect TLS if it is reused. Let's suppose there are not much traffic between two proxys and the TLSes have not been used for a long time, it should be possible to disconnect them. Even though there are no any application layer data, but much connection will reduce the performance quickly, especially TCP and TLS. Regards, Rocky Wang _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 10:17:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53U-0007AV-LZ; Wed, 22 Mar 2006 10:15:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53S-00079R-Gf for sip@ietf.org; Wed, 22 Mar 2006 10:15:22 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM53Q-00037P-Kn for sip@ietf.org; Wed, 22 Mar 2006 10:15:22 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ00IOMBZTAY@szxga03-in.huaweiFrom sip-bounces@ietf.org Wed Mar 22 10:17:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53S-00079W-QW; Wed, 22 Mar 2006 10:15:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53Q-00079E-0i for sip@ietf.org; Wed, 22 Mar 2006 10:15:20 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM53O-00037P-3c for sip@ietf.org; Wed, 22 Mar 2006 10:15:19 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ00INHBZSAY@szxga03-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 23:21:28 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ0067IBY7CR@szxga03-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 23:21:28 +0800 (CST) Received: from jys3105061846 (DHCP-Wireless-132-2.ietf65.org [130.129.132.2]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWJ0033WBDS0Q@szxml02-in.huawei.com>; Wed, 22 Mar 2006 23:08:26 +0800 (CST) Date: Wed, 22 Mar 2006 08:55:09 -0600 From: Rocky Wang To: rohan@ekabal.com, brett@broadsoft.com Message-id: <010301c64dc0$9f782ab0$d6858182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZNwJz2mRAFyW5lSAaaJh57la1/Jg== X-Spam-Score: 1.6 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org 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: , Errors-To: sip-bounces@ietf.org Hi, Rohan and Brett, Why should we limit only one TLS connection between two entities? Suppose there are a huge traffic between proxys or proxy and application server, one TLS maybe will limit the traffic and application. I think they can keep and select a TLS connection if there are some, for example, load balance. And we should not mandate that the entities MUST NOT disconnect TLS if it is reused. Let's suppose there are not much traffic between two proxys and the TLSes have not been used for a long time, it should be possible to disconnect them. Even though there are no any application layer data, but much connection will reduce the performance quickly, especially TCP and TLS. Regards, Rocky Wang _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 10:17:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53U-0007AV-LZ; Wed, 22 Mar 2006 10:15:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53S-00079R-Gf for sip@ietf.org; Wed, 22 Mar 2006 10:15:22 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM53Q-00037P-Kn for sip@ietf.org; Wed, 22 Mar 2006 10:15:22 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ00IOMBZTAY@szxga03-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 23:21:29 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ0067JBY7CR@szxga03-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 23:21:29 +0800 (CST) Received: from jys3105061846 (DHCP-Wireless-132-2.ietf65.org [130.129.132.2]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWJ00377BG90Q@szxml02-in.huawei.com>; Wed, 22 Mar 2006 23:10:03 +0800 (CST) Date: Wed, 22 Mar 2006 08:56:38 -0600 From: Rocky Wang To: rohan@ekabal.com, brett@broadsoft.com Message-id: <010401c64dc0$d81c22e0$d6858182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZNwNH6V6NLLFa3Q/WQXbXRbG2Igg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org Subject: [Sip] Some doubts about draft-ietf-sip-connect-reuse-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 Hi, Rohan and Brett, Why should we limit only one TLS connection between two entities? Suppose there are a huge traffic between proxys or proxy and application server, one TLS maybe will limit the traffic and application. I think they can keep and select a TLS connection if there are some, for example, load balance. And we should not mandate that the entities MUST NOT disconnect TLS if it is reused. Let's suppose there are not much traffic between two proxys and the TLSes have not been used for a long time, it should be possible to disconnect them. Even though there are no any application layer data, but much connection will reduce the performance quickly, especially TCP and TLS. Regards, Rocky Wang _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip .com> for sip@ietf.org; Wed, 22 Mar 2006 23:21:29 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ0067JBY7CR@szxga03-in.huawei.com> for sip@ietf.org; Wed, 22 Mar 2006 23:21:29 +0800 (CST) Received: from jys3105061846 (DHCP-Wireless-132-2.ietf65.org [130.129.132.2]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWJ00377BG90Q@szxml02-in.huawei.com>; Wed, 22 Mar 2006 23:10:03 +0800 (CST) Date: Wed, 22 Mar 2006 08:56:38 -0600 From: Rocky Wang To: rohan@ekabal.com, brett@broadsoft.com Message-id: <010401c64dc0$d81c22e0$d6858182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZNwNH6V6NLLFa3Q/WQXbXRbG2Igg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org Subject: [Sip] Some doubts about draft-ietf-sip-connect-reuse-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 Hi, Rohan and Brett, Why should we limit only one TLS connection between two entities? Suppose there are a huge traffic between proxys or proxy and application server, one TLS maybe will limit the traffic and application. I think they can keep and select a TLS connection if there are some, for example, load balance. And we should not mandate that the entities MUST NOT disconnect TLS if it is reused. Let's suppose there are not much traffic between two proxys and the TLSes have not been used for a long time, it should be possible to disconnect them. Even though there are no any application layer data, but much connection will reduce the performance quickly, especially TCP and TLS. Regards, Rocky Wang _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 10:17:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53i-0007SM-4n; Wed, 22 Mar 2006 10:15:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53g-0007SH-Lq for sip@ietf.org; Wed, 22 Mar 2006 10:15:36 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM53f-0003Dc-C4 for sip@ietf.org; Wed, 22 Mar 2006 10:15:36 -0500 Received: from dhcp-wireless-134-205.ietf65.org ([130.129.134.205]) by dns.aliantmedia.net with esmtpa (Exim 4.52) id 1FM53P-0005EH-RG; Wed, 22 Mar 2006 09:15:19 -0600 Message-ID: <44216A05.6080904@ntt-at.com> Date: Wed, 22 Mar 2006 07:15:17 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 References: <50B1CBA96870A34799A506B2313F266708755F06@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F266708755F06@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.2 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 agree with John with the consensus of the room. Regards Shida Schubert Elwell, John wrote: > Rocky, > > The connected-identity draft is not a subset of the response identity draft. > The response identity draft cannot be used to indicate a change of party > mid-dialog. > > I don't think we can merge them. There was no consensus on the response > identity draft. The following views have been expressed: > - that it does not provide any benefit; > - that the response identity problem cannot be solved, and that the approach > taken in the connected-identity draft is the best that can be achieved. > > If and when there is consensus on a response identity solution, then we > could consider whether it would be appropriate to merge the two, but that is > not the case at present. > > John > > >> -----Original Message----- >> From: Rocky Wang [mailto:rocky.wang@huawei.com] >> Sent: 21 March 2006 19:50 >> To: sip@ietf.org >> Subject: [Sip] draft-cao-sip-response-identity-00 and >> draft-elwell-sip-connected-identity-01 >> >> >> Both of draft-cao-sip-response-identity-00 and >> draft-elwell-sip-connected-identity-01 have been disscussed >> in today's SIP >> session. I found they two can be merged into one. >> The first one is a common requirement to return back the identity >> identifier. It can be used in both successful responses, but also in >> provisiional, redirect and failure responses, but the 2nd one >> is just used >> for 18X and 2XX response for INVITE (maybe also some other >> type requests). >> As I considered, the 2nd one is just a sub-set case of the >> first one. Can >> merge the 2nd one into the 1st one? Or merge the requirement >> of the 1st into >> the last. >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 11:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6NJ-0004xZ-Us; Wed, 22 Mar 2006 11:39:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6NI-0004xQ-OW for sip@ietf.org; Wed, 22 Mar 2006 11:39:56 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6NF-00077b-6l for sip@ietf.org; Wed, 22 Mar 2006 11:39:56 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 16:39:51 +0000 Received: from i2km08-ukbr.domain1.systemhost.net ([193.113.197.82]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 16:39:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Mar 2006 16:39:51 -0000 Message-ID: <9D598A34672DF24F89FF4F851A41619517D25151@i2km08-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Overload control per protocol or an over load protocol thread-index: AcZNzzGWPVHYjK46Sc+dhzOLjxWjyw== From: To: X-OriginalArrivalTime: 22 Mar 2006 16:39:51.0574 (UTC) FILETIME=[3DB8FB60:01C64DCF] X-Spam-Score: 0.2 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Sip] Overload control per protocol or an over load 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: , Content-Type: multipart/mixed; boundary="===============1750856148==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1750856148== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64DCF.3D926DB4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64DCF.3D926DB4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All The draft-rosenberg-sipping-overload-reqs-00.txt proposes the requirement for fixing the SIP overload mechanisms, which even if accepted only fixes part of the problem of a overloaded server. This is because the server may not be overloaded just because of SIP sessions, it is just as likely that a server would go into overload because of its processing a number of different protocols all of which may be unaware of each other.=20 Would a solution to this problem is to scope and define a single protocol that could interact with all the entities/nodes/proxies/servers etc. that are directly connected to the overloaded server so they back off from sending messages to the overloaded server.=20 This work is currently being underway in ETSI TISPAN called GOCAP which can be found at http://portal.etsi.org/docbox/TISPAN/Open/NGN%20LATEST%20DRAFTS/02026v00 6.pdf and this will give the latest draft of the work ongoing in TISPAN to define the architect and requirements for a overload protocol.=20 To me it makes no sense to have many different solutions to this problem and I would like to know if there are people out there who would be interested in progressing this type of work both in the IETF and in the TISPAN community. Regards Steve Norreys ------_=_NextPart_001_01C64DCF.3D926DB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Overload control per protocol or an over load protocol

All

The = draft-rosenberg-sipping-overload-reqs-00.txt proposes the requirement = for fixing the SIP overload mechanisms, which even if accepted only = fixes part of the problem of a overloaded server.  This is because = the server may not be overloaded just because of SIP sessions, it is = just as likely that a server would go into overload because of its = processing a number of different protocols all of which may be unaware = of each other.

Would a solution to this problem is to = scope and define a single protocol that could interact with all the = entities/nodes/proxies/servers etc. that are directly connected to the = overloaded server so they back off from sending messages to the = overloaded server.

This work is currently being underway = in ETSI TISPAN called GOCAP which can be found at http://portal.etsi.org/docbox/TISPAN/Open/NGN%20LATEST%20D= RAFTS/02026v006.pdf and = this will give the latest draft of the work ongoing in TISPAN to define = the architect and requirements for a overload protocol.

To me it makes no sense to have many = different solutions to this problem and I would like to know if there = are people out there who would be interested in progressing this type of = work both in the IETF and in the TISPAN community.


Regards

Steve = Norreys

------_=_NextPart_001_01C64DCF.3D926DB4-- --===============1750856148== 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 --===============1750856148==-- From sip-bounces@ietf.org Wed Mar 22 13:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7yk-0000Uy-RV; Wed, 22 Mar 2006 13:22:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrb3-00054y-6M for sip@ietf.org; Tue, 21 Mar 2006 19:53:09 -0500 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 1FLrb1-0004Xt-No for sip@ietf.org; Tue, 21 Mar 2006 19:53:09 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2M0pl7Q072483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 18:51:48 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <44209FA0.1060506@estacado.net> Date: Tue, 21 Mar 2006 18:51:44 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] RFC3261: Errata? References: <4420685B.3080804@nostrum.com> <44207227.20907@cisco.com> <44208976.50800@nostrum.com> <4420963E.9050607@cisco.com> In-Reply-To: <4420963E.9050607@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Wed, 22 Mar 2006 13:22:41 -0500 Cc: sip@ietf.org, Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > We could ask the rfc-editor to link to the bugzilla site. That would seem to be a suitable solution to the situation. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 22 13:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7yk-0000Ur-01; Wed, 22 Mar 2006 13:22:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLq4D-0006Ke-Tj for sip@ietf.org; Tue, 21 Mar 2006 18:15:09 -0500 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 1FLq4B-0000Jq-Pi for sip@ietf.org; Tue, 21 Mar 2006 18:15:09 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2LNF03b050169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 17:15:03 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <442088F2.2010707@estacado.net> Date: Tue, 21 Mar 2006 17:14:58 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] RFC3261: Errata? References: <4420685B.3080804@nostrum.com> <44207227.20907@cisco.com> In-Reply-To: <44207227.20907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Wed, 22 Mar 2006 13:22:41 -0500 Cc: sipFrom sip-bounces@ietf.org Wed Mar 22 13:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7yk-0000Uy-RV; Wed, 22 Mar 2006 13:22:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrb3-00054y-6M for sip@ietf.org; Tue, 21 Mar 2006 19:53:09 -0500 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 1FLrb1-0004Xt-No for sip@ietf.org; Tue, 21 Mar 2006 19:53:09 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2M0pl7Q072483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 18:51:48 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <44209FA0.1060506@estacado.net> Date: Tue, 21 Mar 2006 18:51:44 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] RFC3261: Errata? References: <4420685B.3080804@nostrum.com> <44207227.20907@cisco.com> <44208976.50800@nostrum.com> <4420963E.9050607@cisco.com> In-Reply-To: <4420963E.9050607@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Wed, 22 Mar 2006 13:22:41 -0500 Cc: sip@ietf.org, Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > We could ask the rfc-editor to link to the bugzilla site. That would seem to be a suitable solution to the situation. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 22 13:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7yk-0000Ur-01; Wed, 22 Mar 2006 13:22:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLq4D-0006Ke-Tj for sip@ietf.org; Tue, 21 Mar 2006 18:15:09 -0500 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 1FLq4B-0000Jq-Pi for sip@ietf.org; Tue, 21 Mar 2006 18:15:09 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2LNF03b050169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 17:15:03 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <442088F2.2010707@estacado.net> Date: Tue, 21 Mar 2006 17:14:58 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] RFC3261: Errata? References: <4420685B.3080804@nostrum.com> <44207227.20907@cisco.com> In-Reply-To: <44207227.20907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Wed, 22 Mar 2006 13:22:41 -0500 Cc: sip@ietf.org, Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > I think thats just more confusing; it would mean that there are two > places to go to for errata, and we need to keep them in sync. I'd > prefer to stick with bugzilla as the primary source. I understand the sentiment. The issue is that there's this kind-of well known place (at least, for people who have a passing familiarity with the IETF) that people can go to find RFC errata. It's a bit hard to find for the uninitiated, but the fact that the mechanism is the same for some 4000+ documents gives it *some* visibility. On top of that, we add what looks to an outsider like our own uber-secret-handshake hidden repository of SIP errata, and I'm not sure how anyone is ever going to benefit from the collected SIPit knowledge until we publish 3261bis. Am I missing some kind of pointer that is likely to lead implementors, vendors, and operators to the bugzilla database? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip @ietf.org, Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > I think thats just more confusing; it would mean that there are two > places to go to for errata, and we need to keep them in sync. I'd > prefer to stick with bugzilla as the primary source. I understand the sentiment. The issue is that there's this kind-of well known place (at least, for people who have a passing familiarity with the IETF) that people can go to find RFC errata. It's a bit hard to find for the uninitiated, but the fact that the mechanism is the same for some 4000+ documents gives it *some* visibility. On top of that, we add what looks to an outsider like our own uber-secret-handshake hidden repository of SIP errata, and I'm not sure how anyone is ever going to benefit from the collected SIPit knowledge until we publish 3261bis. Am I missing some kind of pointer that is likely to lead implementors, vendors, and operators to the bugzilla database? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 22 13:46:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8KO-0007FZ-CY; Wed, 22 Mar 2006 13:45:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8KM-0007CN-0j for sip@ietf.org; Wed, 22 Mar 2006 13:45:02 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM8KL-0004lM-Gu for sip@ietf.org; Wed, 22 Mar 2006 13:45:01 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWJ00F01LAFVX@siemenscomms.co.uk> for sip@ietf.org; Wed, 22 Mar 2006 18:42:15 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWJ00E6ZLAEP0@siemenscomms.co.uk>; Wed, 22 Mar 2006 18:42:14 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Mar 2006 18:45:00 +0000 Content-return: allowed Date: Wed, 22 Mar 2006 18:44:41 +0000 From: "Elwell, John" Subject: RE: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 To: Rocky Wang , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667087568F8@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 1.1 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 Rocky, The connected-identity draft already gives two examples why a mid-dialog change would be needed: PSTN gateway and B2BUA. We could define a new header field for response identity if this can be justified, but it would not be secure. I think the consensus yesterday was to move forward with connected-identity and consider separately whether response identity is achievable in a way that is secure as well as adding some value in certain use cases. John > -----Original Message----- > From: Rocky Wang [mailto:rocky.wang@huawei.com] > Sent: 22 March 2006 14:44 > To: Elwell, John; sip@ietf.org > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > draft-elwell-sip-connected-identity-01 > > As my opinion, they two just need take the responser > identifier in the > response messages. We must consider and resolve all the > problem include the > security problems in both cases. > If you want to indicate a change of party mid-dialog, you can use some > mid-dialog method to do it, as I considered, just like UPDATE > and re-INVITE. > That's not so difficult in use of exist mechanism. But can > you please give > me an application case of the usage of mid-dialog entity identifier > indication. > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Tuesday, March 21, 2006 11:44 PM > To: Rocky Wang; sip@ietf.org > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > draft-elwell-sip-connected-identity-01 > > Rocky, > > The connected-identity draft is not a subset of the response > identity draft. > The response identity draft cannot be used to indicate a > change of party > mid-dialog. > > I don't think we can merge them. There was no consensus on > the response > identity draft. The following views have been expressed: > - that it does not provide any benefit; > - that the response identity problem cannot be solved, and > that the approach > taken in the connected-identity draft is the best that can be > achieved. > > If and when there is consensus on a response identity > solution, then we > could consider whether it would be appropriate to merge the > two, but that is > not the case at present. > > John > > > -----Original Message----- > > From: Rocky Wang [mailto:rocky.wang@huawei.com] > > Sent: 21 March 2006 19:50 > > To: sip@ietf.org > > Subject: [Sip] draft-cao-sip-response-identity-00 and > > draft-elwell-sip-connected-identity-01 > > > > > > Both of draft-cao-sip-response-identity-00 and > > draft-elwell-sip-connected-identity-01 have been disscussed > in today's > > SIP session. I found they two can be merged into one. > > The first one is a common requirement to return back the identity > > identifier. It can be used in both successful responses, > but also in > > provisiional, redirect and failure responses, but the 2nd > one is just > > used for 18X and 2XX response for INVITE (maybe also some > other type > > requests). > > As I considered, the 2nd one is just a sub-set case of the > first one. > > Can merge the 2nd one into the 1st one? Or merge the requirement of > > the 1st into the last. > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 15:13:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9gJ-0000TD-99; Wed, 22 Mar 2006 15:11:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9gI-0000P3-F1 for sip@ietf.org; Wed, 22 Mar 2006 15:11:46 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9gH-0008LV-5D for sip@ietf.org; Wed, 22 Mar 2006 15:11:46 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2MKBR6Q008994; Wed, 22 Mar 2006 14:11:27 -0600 (CST) Received: from [135.244.0.66] (vkg.lra2.lucent.com [135.244.0.66] (may be forged)) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2MKBNA08551; Wed, 22 Mar 2006 14:11:23 -0600 (CST) Message-ID: <4421AF6C.4070802@lucent.com> Date: Wed, 22 Mar 2006 14:11:24 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rocky Wang Subject: Re: [Sip] Some doubts about draft-ietf-sip-connect-reuse-05 References: <010401c64dc0$d81c22e0$d6858182@china.huawei.com> In-Reply-To: <010401c64dc0$d81c22e0$d6858182@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, rohan@ekabal.com, brett@broadsoft.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 Rocky Wang wrote: > Hi, Rohan and Brett, Why should we limit only one TLS connection > between two entities? Suppose there are a huge traffic between proxys > or proxy and application server, one TLS maybe will limit the traffic > and application. I think they can keep and select a TLS connection if > there are some, for example, load balance. Load balancing through SRV mechanism is accounted for in the current draft. You do not need to do anything special. > And we should not mandate that the entities MUST NOT disconnect TLS > if it is reused. Let's suppose there are not much traffic between two > proxys and the TLSes have not been used for a long time, it should be > possible to disconnect them. Even though there are no any application > layer data, but much connection will reduce the performance quickly, > especially TCP and TLS. I don't think that the draft mandates with normative strength that idle connections should be kept open *indefinately*. When to close a connection is an implementation defined issue; at the minimum, to get the most benefit out of connection reuse, the implementation should not close sockets after every transaction and/or dialog. Some implementations may choose to close connections when the number of open connections have reached a high watermark, others may want to close them when they have been idle for some time (implementation defined). 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 Mar 22 15:34:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA07-00071h-Pi; Wed, 22 Mar 2006 15:32:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA05-0006zK-Be; Wed, 22 Mar 2006 15:32:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMA04-0000bQ-3S; Wed, 22 Mar 2006 15:32:13 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2006 12:32:11 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="263565796:sNHT29079112" Received: from dwingwxp (sjc-vpn1-425.cisco.com [10.21.97.169]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2MKWA1j012474; Wed, 22 Mar 2006 12:32:10 -0800 (PST) From: "Dan Wing" To: , , , , "'sip ietf'" Date: Wed, 22 Mar 2006 12:32:10 -0800 Message-ID: <01b901c64def$b2756b80$9353150a@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: AcZN77HHQKFiD7TtT+Wrd/AK1m0kjA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Sip] VoIP security mailing 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 During my RAI presentation yesterday a few people said they were unfamiliar with the VoIP security mailing list that I referred to. The mailing list is run by the VoIP Security Alliance . The page has links to subscribe and view archives. -Dan Wing _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 15:47:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMADP-0000OH-0j; Wed, 22 Mar 2006 15:45:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMADN-0000OC-Nu for sip@ietf.org; Wed, 22 Mar 2006 15:45:57 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMADM-0001J8-GX for sip@ietf.org; Wed, 22 Mar 2006 15:45:57 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2MKjtea015595 for ; Wed, 22 Mar 2006 14:45:55 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Mar 2006 20:45:54 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB012748E5D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Wed, 22 Mar 2006 20:45:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sip] draft-ietf-sip-fork-loop-fix X-BeenThere: sip@ietf.org X-Mailman-Version: 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 chair) The face-to-face sip session in ietf 65 identified that draft-ietf-sip-fork-loop-fix is ready as follows. WGLC/Publish this draft at current scope (loop detection only) Continue discussions on other potential improvements as separate efforts Robert will update the draft for resubmission as -01 early next week with the following changes (plus some nit fixes): change 1: SHOULD use 3261 loop detection will change to MAY change 2: branches to connections created using the outbound mechanism won't count towards requiring loop detection. That is, loop detection will be MUST if retargetting to more than one branch that is not a connection established with outbound. If any members of the WG believe that this draft, with the identified revisions, is not ready to move to WGLC, then please identify this to the list, giving appropriate reasons for your opinion. Additionally, if there are any NITS or other issues you have noticed that need fixing, then please send them quickly to the list or the authors as appropriate in order that the version going for WGLC includes as many fixes as possible. regards Keith, Dean Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 15:48:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAEX-0001Z9-48; Wed, 22 Mar 2006 15:47:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAEV-0001XO-2i for sip@ietf.org; Wed, 22 Mar 2006 15:47:07 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAET-0001Mm-5v for sip@ietf.org; Wed, 22 Mar 2006 15:47:07 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ0061ARKCCB@szxga01-in.huawei.com> for sip@ietf.org; Thu, 23 Mar 2006 04:57:48 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ007D8RKC3N@szxga01-in.huawei.com> for sip@ietf.org; Thu, 23 Mar 2006 04:57:48 +0800 (CST) Received: from jys3105061846 (DHCP-Wireless-132-2.ietf65.org [130.129.132.2]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWJ009RWRNCN0@szxml02-in.huawei.com>; Thu, 23 Mar 2006 05:00:03 +0800 (CST) Date: Wed, 22 Mar 2006 14:46:24 -0600 From: Rocky Wang Subject: RE: [Sip] Some doubts about draft-ietf-sip-connect-reuse-05 In-reply-to: <4421AF6C.4070802@lucent.com> To: "'Vijay K. Gurbani'" Message-id: <000601c64df1$bc52d500$02848182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZN7NlNqO9SQO18R3O4plbZjORdmgABBwUA X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sip@ietf.org, rohan@ekabal.com, brett@broadsoft.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 Vijay K. Gurbani wrote: > > Rocky Wang wrote: > > Hi, Rohan and Brett, Why should we limit only one TLS connection > > between two entities? Suppose there are a huge traffic > between proxys > > or proxy and application server, one TLS maybe will limit > the traffic > > and application. I think they can keep and select a TLS > connection if > > there are some, for example, load balance. > > Load balancing through SRV mechanism is accounted for in the > current draft. You do not need to do anything special. The following sentense is from the client behavior part of the draft. Maybe I missed something. And furthermore, it MUST reuse the connection when subsequent requests in the same or different transactions are destined to the same resolved address. Whether or not to allow an aliased connection ultimately depends on the recepient of the request. Thus, clients MUST NOT assume that the acceptance of a request by a server automatically enables connection aliasing. They MUST continue receiving requests on their default port. > > > And we should not mandate that the entities MUST NOT > disconnect TLS if > > it is reused. Let's suppose there are not much traffic between two > > proxys and the TLSes have not been used for a long time, it > should be > > possible to disconnect them. Even though there are no any > application > > layer data, but much connection will reduce the performance > quickly, > > especially TCP and TLS. > > I don't think that the draft mandates with normative strength > that idle connections should be kept open *indefinately*. > When to close a connection is an implementation defined > issue; at the minimum, to get the most benefit out of > connection reuse, the implementation should not close sockets > after every transaction and/or dialog. Some implementations > may choose to close connections when the number of open > connections have reached a high watermark, others may want to > close them when they have been idle for some time > (implementation defined). The following part is also from the client behavior part of the draft. Please help me to check it. The implications of placing an "alias" parameter in the topmost Via header of a request must be understood by the client. Specifically, this means that the client MUST keep the connection open for as long as the resources on the host operating system allow it to, and that it MUST accept requests over this connection -- as opposed to a default listening port -- from its downstream peer. > > Thanks, > > - vijay > Thanks, Rocky Wang _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 16:03:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMASE-0007XR-M5; Wed, 22 Mar 2006 16:01:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMASD-0007RU-AW for sip@ietf.org; Wed, 22 Mar 2006 16:01:17 -0500 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 1FMASC-0002Q3-TY for sip@ietf.org; Wed, 22 Mar 2006 16:01:17 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 22 Mar 2006 13:01:12 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="419326691:sNHT31829104" Received: from billybong.cisco.com (billybong.cisco.com [171.71.163.234]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2ML1C7U000760; Wed, 22 Mar 2006 13:01:12 -0800 (PST) Date: Wed, 22 Mar 2006 13:01:12 -0800 (PST) From: Feng Cao To: "Elwell, John" Subject: RE: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 In-Reply-To: <50B1CBA96870A34799A506B2313F2667087568F8@ntht201e.siemenscomms.co.uk> Message-ID: References: <50B1CBA96870A34799A506B2313F2667087568F8@ntht201e.siemenscomms.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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 Because connected-id is revealed in the mid-dialog, there are some scenarios that are not covered by connected-identity draft. In general, I agreed with Rocky that the mid-dialog update can be easily convered or embeded into the sip identity draft by Jon and Cullen. I don't see the need of another new draft for it. Some useful scenarios for response identity inside response messages had been listed for discussion: 1. disclose the response identity for non-dialog session. 2. reveal the proxy's identity as the responder for some response codes, such as provisiional, redirect and failure responses. This will help the callers to make decisions. 3. prevent the identity spoofing as early as possible. In some cases, it is too late to be notifies of the response identity after the dialogs are established. --Feng On Wed, 22 Mar 2006, Elwell, John wrote: > Rocky, > > The connected-identity draft already gives two examples why a mid-dialog > change would be needed: PSTN gateway and B2BUA. > > We could define a new header field for response identity if this can be > justified, but it would not be secure. I think the consensus yesterday was > to move forward with connected-identity and consider separately whether > response identity is achievable in a way that is secure as well as adding > some value in certain use cases. > > John > > >> -----Original Message----- >> From: Rocky Wang [mailto:rocky.wang@huawei.com] >> Sent: 22 March 2006 14:44 >> To: Elwell, John; sip@ietf.org >> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >> draft-elwell-sip-connected-identity-01 >> >> As my opinion, they two just need take the responser >> identifier in the >> response messages. We must consider and resolve all the >> problem include the >> security problems in both cases. >> If you want to indicate a change of party mid-dialog, you can use some >> mid-dialog method to do it, as I considered, just like UPDATE >> and re-INVITE. >> That's not so difficult in use of exist mechanism. But can >> you please give >> me an application case of the usage of mid-dialog entity identifier >> indication. >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Tuesday, March 21, 2006 11:44 PM >> To: Rocky Wang; sip@ietf.org >> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >> draft-elwell-sip-connected-identity-01 >> >> Rocky, >> >> The connected-identity draft is not a subset of the response >> identity draft. >> The response identity draft cannot be used to indicate a >> change of party >> mid-dialog. >> >> I don't think we can merge them. There was no consensus on >> the response >> identity draft. The following views have been expressed: >> - that it does not provide any benefit; >> - that the response identity problem cannot be solved, and >> that the approach >> taken in the connected-identity draft is the best that can be >> achieved. >> >> If and when there is consensus on a response identity >> solution, then we >> could consider whether it would be appropriate to merge the >> two, but that is >> not the case at present. >> >> John >> >>> -----Original Message----- >>> From: Rocky Wang [mailto:rocky.wang@huawei.com] >>> Sent: 21 March 2006 19:50 >>> To: sip@ietf.org >>> Subject: [Sip] draft-cao-sip-response-identity-00 and >>> draft-elwell-sip-connected-identity-01 >>> >>> >>> Both of draft-cao-sip-response-identity-00 and >>> draft-elwell-sip-connected-identity-01 have been disscussed >> in today's >>> SIP session. I found they two can be merged into one. >>> The first one is a common requirement to return back the identity >>> identifier. It can be used in both successful responses, >> but also in >>> provisiional, redirect and failure responses, but the 2nd >> one is just >>> used for 18X and 2XX response for INVITE (maybe also some >> other type >>> requests). >>> As I considered, the 2nd one is just a sub-set case of the >> first one. >>> Can merge the 2nd one into the 1st one? Or merge the requirement of >>> the 1st into the last. >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 18:44:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMCy2-0000DE-KN; Wed, 22 Mar 2006 18:42:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMCy0-0000By-PB for sip@ietf.org; Wed, 22 Mar 2006 18:42:16 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMCxx-0000SZ-Pj for sip@ietf.org; Wed, 22 Mar 2006 18:42:16 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ00EO6ZO99W@szxga01-in.huawei.com> for sip@ietf.org; Thu, 23 Mar 2006 07:52:57 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWJ00LHGZO8EX@szxga01-in.huawei.com> for sip@ietf.org; Thu, 23 Mar 2006 07:52:57 +0800 (CST) Received: from jys3105061846 (DHCP-Wireless-132-2.ietf65.org [130.129.132.2]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWJ009NKZQYN0@szxml02-in.huawei.com>; Thu, 23 Mar 2006 07:55:12 +0800 (CST) Date: Wed, 22 Mar 2006 17:41:23 -0600 From: Rocky Wang Subject: RE: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip-connected-identity-01 In-reply-to: <50B1CBA96870A34799A506B2313F2667087568F8@ntht201e.siemenscomms.co.uk> To: "'Elwell, John'" , sip@ietf.org Message-id: <003401c64e0a$332e4e30$02848182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZN4MRrqovX/PLBQSCnNUXnEfNtkQAINqQg X-Spam-Score: 1.1 (+) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 with you that there are some requirements to convey the changed identifier. But I think UPDATE and re-INVITE can be used to do so, that is no need to create a 2nd solution. Apart from the mid-dialog requiements, the Connect-URI can be considered as a sub-set of the response identifier. Today we are discussing about conveying the connected URI that return the response, tomorrow, maybe we must re-consider how to convey the identifier which return responses and then we must do the same thing again, including the security and some other problems. What I want to say is that the two drafts can be merged easily from the requirement and expected solution aspects because they are overlapped with each other, and we should do so as my owner opinion. Rocky Wang > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Wednesday, March 22, 2006 12:45 PM > To: Rocky Wang; sip@ietf.org > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > draft-elwell-sip-connected-identity-01 > > Rocky, > > The connected-identity draft already gives two examples why a > mid-dialog change would be needed: PSTN gateway and B2BUA. > > We could define a new header field for response identity if > this can be justified, but it would not be secure. I think > the consensus yesterday was to move forward with > connected-identity and consider separately whether response > identity is achievable in a way that is secure as well as > adding some value in certain use cases. > > John > > > > -----Original Message----- > > From: Rocky Wang [mailto:rocky.wang@huawei.com] > > Sent: 22 March 2006 14:44 > > To: Elwell, John; sip@ietf.org > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > > draft-elwell-sip-connected-identity-01 > > > > As my opinion, they two just need take the responser identifier in > > the response messages. We must consider and resolve all the problem > > include the security problems in both cases. > > If you want to indicate a change of party mid-dialog, you > can use some > > mid-dialog method to do it, as I considered, just like UPDATE and > > re-INVITE. > > That's not so difficult in use of exist mechanism. But can > you please > > give me an application case of the usage of mid-dialog entity > > identifier indication. > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Tuesday, March 21, 2006 11:44 PM > > To: Rocky Wang; sip@ietf.org > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > > draft-elwell-sip-connected-identity-01 > > > > Rocky, > > > > The connected-identity draft is not a subset of the > response identity > > draft. > > The response identity draft cannot be used to indicate a change of > > party mid-dialog. > > > > I don't think we can merge them. There was no consensus on the > > response identity draft. The following views have been expressed: > > - that it does not provide any benefit; > > - that the response identity problem cannot be solved, and that the > > approach taken in the connected-identity draft is the best > that can be > > achieved. > > > > If and when there is consensus on a response identity > solution, then > > we could consider whether it would be appropriate to merge the two, > > but that is not the case at present. > > > > John > > > > > -----Original Message----- > > > From: Rocky Wang [mailto:rocky.wang@huawei.com] > > > Sent: 21 March 2006 19:50 > > > To: sip@ietf.org > > > Subject: [Sip] draft-cao-sip-response-identity-00 and > > > draft-elwell-sip-connected-identity-01 > > > > > > > > > Both of draft-cao-sip-response-identity-00 and > > > draft-elwell-sip-connected-identity-01 have been disscussed > > in today's > > > SIP session. I found they two can be merged into one. > > > The first one is a common requirement to return back the identity > > > identifier. It can be used in both successful responses, > > but also in > > > provisiional, redirect and failure responses, but the 2nd > > one is just > > > used for 18X and 2XX response for INVITE (maybe also some > > other type > > > requests). > > > As I considered, the 2nd one is just a sub-set case of the > > first one. > > > Can merge the 2nd one into the 1st one? Or merge the > requirement of > > > the 1st into the last. > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 18:52:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMD5o-0005u3-UN; Wed, 22 Mar 2006 18:50:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMD5X-0005ee-Fp; Wed, 22 Mar 2006 18:50:03 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMD5W-0000aK-VO; Wed, 22 Mar 2006 18:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k2MNo2vP026495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FMD5W-0002GB-Gl; Wed, 22 Mar 2006 18:50:02 -0500 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, 22 Mar 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.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-03.txt Pages : 31 Date : 2006-3-22 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. Even when a proxy server can open a TCP connection to a User Agent, most User Agents lack a certificate suitable to act as a TLS (Transport Layer Security) server. 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-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-outbound-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-outbound-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-22171203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-22171203.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 Mar 22 20:32:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEeZ-0001RI-If; Wed, 22 Mar 2006 20:30:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEeX-0001Qk-Pe for sip@ietf.org; Wed, 22 Mar 2006 20:30:17 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMEeX-0007S4-63 for sip@ietf.org; Wed, 22 Mar 2006 20:30:17 -0500 Received: from [204.96.115.208] ([204.96.115.208]) by server (8.12.8/8.12.8) with SMTP id k2N0332w009531; Wed, 22 Mar 2006 19:03:04 -0500 Message-ID: <4421F997.8090505@ntt-at.com> Date: Wed, 22 Mar 2006 17:27:51 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Rocky Wang Subject: Re: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip-connected-identity-01 References: <003401c64e0a$332e4e30$02848182@china.huawei.com> In-Reply-To: <003401c64e0a$332e4e30$02848182@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: sip@ietf.org, "'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 Hi Rocky; Why do you want the response identity so bad? - As I understand there are two issues, response identity is trying to solve. Issue 1. Who am I really connected to and is it really who it claims it is? - Connected Identity solves this problem by allowing the changes in From header field and re-using the SIP-Identity spec. The Connected-Identity spec is nice because it reuses what's already there and does not introduce any new header for indicating identity. And inherit all the nice traits identity header provides such as integrity etc. - Response Identity tries to provide the same thing by introducing few new headers which clutters the header with more Identity related information. Beside there are few issues with how one should trust the response-identity(Proxy unable to authorize the response etc.). Issue 2. Am I connected to foo as a result of routing decision based on my INVITE? - Can't really solve the issue with neither of the solution described above. Issue 2 can't be solved by neither of the solution and Issue 1 can be solved with Connected Identity without adding any extra identity related header. So I personally don't know why you are so persistent with adopting them both? I think Connected-Identity alone satisfies what the WG wants, but I could be completely wrong. As for other reason why I don't think they should merge, currently they propose two completely different solution to address the same problem yet at different timing. And let's not forget, merging the work would create dependency on each spec and results in creating a delays in overall progress. I have been hearing that WG wants to resolve Issue 1, in which case delay due to the merge is likely to be unacceptable. Regards Shida Schubert Rocky Wang wrote: > I agree with you that there are some requirements to convey the changed > identifier. But I think UPDATE and re-INVITE can be used to do so, that is > no need to create a 2nd solution. > Apart from the mid-dialog requiements, the Connect-URI can be considered as > a sub-set of the response identifier. Today we are discussing about > conveying the connected URI that return the response, tomorrow, maybe we > must re-consider how to convey the identifier which return responses and > then we must do the same thing again, including the security and some other > problems. > What I want to say is that the two drafts can be merged easily from the > requirement and expected solution aspects because they are overlapped with > each other, and we should do so as my owner opinion. > > Rocky Wang > > > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Wednesday, March 22, 2006 12:45 PM >> To: Rocky Wang; sip@ietf.org >> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >> draft-elwell-sip-connected-identity-01 >> >> Rocky, >> >> The connected-identity draft already gives two examples why a >> mid-dialog change would be needed: PSTN gateway and B2BUA. >> >> We could define a new header field for response identity if >> this can be justified, but it would not be secure. I think >> the consensus yesterday was to move forward with >> connected-identity and consider separately whether response >> identity is achievable in a way that is secure as well as >> adding some value in certain use cases. >> >> John >> >> >> >>> -----Original Message----- >>> From: Rocky Wang [mailto:rocky.wang@huawei.com] >>> Sent: 22 March 2006 14:44 >>> To: Elwell, John; sip@ietf.org >>> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >>> draft-elwell-sip-connected-identity-01 >>> >>> As my opinion, they two just need take the responser identifier in >>> the response messages. We must consider and resolve all the problem >>> include the security problems in both cases. >>> If you want to indicate a change of party mid-dialog, you >>> >> can use some >> >>> mid-dialog method to do it, as I considered, just like UPDATE and >>> re-INVITE. >>> That's not so difficult in use of exist mechanism. But can >>> >> you please >> >>> give me an application case of the usage of mid-dialog entity >>> identifier indication. >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens.com] >>> Sent: Tuesday, March 21, 2006 11:44 PM >>> To: Rocky Wang; sip@ietf.org >>> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >>> draft-elwell-sip-connected-identity-01 >>> >>> Rocky, >>> >>> The connected-identity draft is not a subset of the >>> >> response identity >> >>> draft. >>> The response identity draft cannot be used to indicate a change of >>> party mid-dialog. >>> >>> I don't think we can merge them. There was no consensus on the >>> response identity draft. The following views have been expressed: >>> - that it does not provide any benefit; >>> - that the response identity problem cannot be solved, and that the >>> approach taken in the connected-identity draft is the best >>> >> that can be >> >>> achieved. >>> >>> If and when there is consensus on a response identity >>> >> solution, then >> >>> we could consider whether it would be appropriate to merge the two, >>> but that is not the case at present. >>> >>> John >>> >>> >>>> -----Original Message----- >>>> From: Rocky Wang [mailto:rocky.wang@huawei.com] >>>> Sent: 21 March 2006 19:50 >>>> To: sip@ietf.org >>>> Subject: [Sip] draft-cao-sip-response-identity-00 and >>>> draft-elwell-sip-connected-identity-01 >>>> >>>> >>>> Both of draft-cao-sip-response-identity-00 and >>>> draft-elwell-sip-connected-identity-01 have been disscussed >>>> >>> in today's >>> >>>> SIP session. I found they two can be merged into one. >>>> The first one is a common requirement to return back the identity >>>> identifier. It can be used in both successful responses, >>>> >>> but also in >>> >>>> provisiional, redirect and failure responses, but the 2nd >>>> >>> one is just >>> >>>> used for 18X and 2XX response for INVITE (maybe also some >>>> >>> other type >>> >>>> requests). >>>> As I considered, the 2nd one is just a sub-set case of the >>>> >>> first one. >>> >>>> Can merge the 2nd one into the 1st one? Or merge the >>>> >> requirement of >> >>>> the 1st into the last. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>>> >>> > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 22 20:32:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEfL-0001zB-EN; Wed, 22 Mar 2006 20:31:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEfK-0001yg-Np for sip@ietf.org; Wed, 22 Mar 2006 20:31:06 -0500 Received: from [199.117.205.100] (helo=ns2.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMEfK-0007X4-6c for sip@ietf.org; Wed, 22 Mar 2006 20:31:06 -0500 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] comments on location conveyance draft X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 22 Mar 2006 19:30:55 -0600 Message-ID: <422D410BD61FC04185076AD99AA7207A01771F16@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZL8H4R86DD5YbOR8u/Me03TiHeAQBNJMwgADzRf9A= From: "McCalmont, Patti" To: "Jean-Francois Mule" X-OriginalArrivalTime: 23 Mar 2006 01:30:59.0304 (UTC) FILETIME=[705EAE80:01C64E19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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 James, I would like to make an additional comment on the requirement that pertains to disabling location. A UAC MUST be prevented from disabling conveyance of location for an emergency call if local jurisdiction (laws of that particular country) requires it. Rational: UACs must abide by regulations for emergency calls as dictated by the local laws (where the emergency event occurs). Patti > UAC-10 A UAC MUST allow its user to be able to disable providing=20 > location within any SIP request message. It is RECOMMENDED=20 > this not be the default configuration of any UA. =20 category: compliance requirement? should this be informative as this is based on "local laws"? or is this a hard requirement that UACs compliant to this SIP location conveyance RFC have to do? proposal: reword to integrate the motivation below. > > Motivation: local laws may give this right to all users within a=20 > jurisdiction, even when the request is initiating an=20 > emergency call. -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Tuesday, March 21, 2006 5:07 PM To: James M. Polk; br@brianrosen.net Cc: sip@ietf.org Subject: RE: [Sip] comments on location conveyance draft James and Brian, Here is a follow-up on SIP location conveyance draft and one of the open issues we discussed in the meeting. It relates to moving the requirements to an annex and expand on one of Jonathan's comment. To recap what I stated at the mike, section 3 of draft02 contains both design requirements (ones you used to craft the location conveyance solution), and, compliance or implementation requirements (requirements applicable to SIP entities implementing the RFC-to-be). The former set could be deleted, moved into an annex or put in a Specific section outlining the requirements that lead to the=20 solution. Some of the compliance requirements should remain in the core document imo to guide implementers and help interop. Here is a first cut at the dichotomy. If you find this is helpful and folks agree with the approach, I'd be willing to continue or propose new text. Jean-Francois. jfm@cablelabs.com --- re: draft-ietf-sip-location-conveyance-02.txt, in >3. Requirements for SIP Location Conveyance > > The following subsections address the requirements placed on > the user agent client, the user agent server, as well as SIP=20 > proxies when conveying location. > UAC-1 The SIP INVITE Method [RFC3261] MUST support Location=20 > Conveyance. category: design requirement; met by the proposed solution in I-D proposal: move to annex or simply remove. > > UAC-2 The SIP MESSAGE method [RFC3428] MUST support Location=20 > Conveyance. category: design requirement; met by the proposed solution in I-D proposal: move to annex or simply remove. > > UAC-3 SIP Requests within a dialog SHOULD support Location=20 > Conveyance. category: compliance requirement?; partially met by the proposed solution in the I-D since the location header is not allowed in ACK and CANCEL requests. proposal: reword to capture the table in section 4.1, here is a basic example with poor wording: [To claim compliance with this document,] a UAC MUST be capable of supporting Location Conveyance in SIP Requests within a dialog as indicated in table xxx. > UAC-4 Other SIP Requests MAY support Location Conveyance. category: design requirement.=20 Not met by the solution since ACK and CAN are marked "-". Indeed, per RFC 3261 section 19.1.1., entries marked "m" are mandatory, those marked "o" are optional, and those marked=20 "-" are not allowed. proposal: move to annex or simply remove. If you agree with the reword above, you also fold this design requirement. > UAC-5 There MUST be one, mandatory to implement means of=20 > transmitting location confidentially. category: design requirement.=20 proposal: remove or reword (i don't understand the requirement here). note: starting a 2119 requirement by words like "there" or "it" is usually a sign that it should be reworded.=20 > Motivation: interoperability=20 > > UAC-6 It MUST be possible for a UAC to update location conveyed=20 > prior to dialog establishment. > Motivation: in case a UAC has moved prior to the establishment of a=20 > dialog between UAs, the UAC must be able to send new location > information. category: compliance or design requirement? proposal: reword to inject the clearer motivation text in the actual requirement. Not sure whether the requirement is on a UAC to be "able" to send new location or the UAS to be capable of receiving and processing location updates. > UAC-7 The privacy and security rules established within [RFC3693]=20 > that would categorize SIP as a 'using protocol' MUST be met. > See Section 7 for analysis. category: design requirement as written proposal: delete as it is addressed in section 7 (also does not only belong to UAC). =20 > UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for=20 > location conveyance within SIP, whether included by-value or=20 > by-reference. category: design requirement as written proposal: reword to capture the UAC requirement, for e.g.,=20 a UAC MUST support/comply with/implement the PIDF-LO=20 location format defined in [RFC4119] as a PIDF-LO.=20 > > Motivation: interoperability=20 note: Especially for interoperability, it would be a plus to also indicate the level of requirement for PIDF-LO "by-value" or "by-value" (is one of them a MUST, are both SHOULD to comply with the SIP Location conveyance RFC)? If this is specified elsewhere, mention it and add a pointer. > UAC-9 A UAC MUST be capable of transmitting a SIP request without=20 > protecting the PIDF-LO message body. It is RECOMMENDED this=20 > not be the default configuration of any UA. This requirement > is orthogonal to the use of TLS or IPSec hop-by-hop between=20 > SIP elements. category: compliance requirement proposal: clarify requirement: how or when does a UAC decide to not "protect" the PIDF-LO msg body part?=20 from a pure requirement point of view, I think you want a MUST for UAC to be capable of protecting the msg body part, *and*, a MAY for the UAC to be able to transmit without it (in some circumstances). > Motivation: If a SIP request is part of an emergency call,=20 > therefore includes the UAC's location, the UAC may understand > through local policy or configuration that a proxy server=20 > will need to learn the UAC's location to route the message=20 > correctly. Using S/MIME on the PIDF-LO defeats this=20 > capability in proxies. note: some of the motivation text should be injected in the requirement. I would recommend getting rid of the "motivation" sub-paragraphs in favor of improved requirement text. > UAC-10 A UAC MUST allow its user to be able to disable providing=20 > location within any SIP request message. It is RECOMMENDED=20 > this not be the default configuration of any UA. =20 category: compliance requirement? should this be informative as this is based on "local laws"? or is this a hard requirement that UACs compliant to this SIP location conveyance RFC have to do? proposal: reword to integrate the motivation below. > > Motivation: local laws may give this right to all users within a=20 > jurisdiction, even when the request is initiating an=20 > emergency call. if this walk through is helpful, I can volunteer to continue or just propose new 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 01:51:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMJdK-00014Z-JQ; Thu, 23 Mar 2006 01:49:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMJdI-00014F-2a for sip@ietf.org; Thu, 23 Mar 2006 01:49:20 -0500 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMJdH-00027q-Jb for sip@ietf.org; Thu, 23 Mar 2006 01:49:20 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 23 Mar 2006 07:49:17 +0100 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Mar 2006 07:49:17 +0100 Message-Id: From: "Jesske, R" To: john.elwell@siemens.com, rocky.wang@huawei.com, sip@ietf.org Subject: AW: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 Date: Thu, 23 Mar 2006 07:49:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 Dear John, looking on your draft, I see the problem with the interworking to the = PSTN/ISDN network. With sending a 200OK in backward direction the PSTN Gateway send an = Answer in ISUP. So there is no chance to send an second Answer because = the call is already switched through. So in such a case new PSTN GWs are needed to wait until the UPDATE is = received. You said that a Header is not secure. What we in TISPAN need is a = secure connected ID and a second from the user send connected ID that = must not be secure. Like as you indicate with your connected ID and the changed From = header. Sorry for asking this question again Why can we not use the P-Asserted-Identity in Responses? It is also a = secure identity. And add only a new header like a connected-From header. Or is this not = generic enough? Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > Gesendet: Mittwoch, 22. M=E4rz 2006 19:45 > An: Rocky Wang; sip@ietf.org > Betreff: RE: [Sip] draft-cao-sip-response-identity-00 and=20 > draft-elwell-sip -connected-identity-01 >=20 >=20 > Rocky, >=20 > The connected-identity draft already gives two examples why a=20 > mid-dialog > change would be needed: PSTN gateway and B2BUA. >=20 > We could define a new header field for response identity if=20 > this can be > justified, but it would not be secure. I think the consensus=20 > yesterday was > to move forward with connected-identity and consider=20 > separately whether > response identity is achievable in a way that is secure as=20 > well as adding > some value in certain use cases. >=20 > John > =20 >=20 > > -----Original Message----- > > From: Rocky Wang [mailto:rocky.wang@huawei.com]=20 > > Sent: 22 March 2006 14:44 > > To: Elwell, John; sip@ietf.org > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and=20 > > draft-elwell-sip-connected-identity-01 > >=20 > > As my opinion, they two just need take the responser=20 > > identifier in the > > response messages. We must consider and resolve all the=20 > > problem include the > > security problems in both cases. > > If you want to indicate a change of party mid-dialog, you=20 > can use some > > mid-dialog method to do it, as I considered, just like UPDATE=20 > > and re-INVITE. > > That's not so difficult in use of exist mechanism. But can=20 > > you please give > > me an application case of the usage of mid-dialog entity identifier > > indication. > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > > Sent: Tuesday, March 21, 2006 11:44 PM > > To: Rocky Wang; sip@ietf.org > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > > draft-elwell-sip-connected-identity-01 > >=20 > > Rocky, > >=20 > > The connected-identity draft is not a subset of the response=20 > > identity draft. > > The response identity draft cannot be used to indicate a=20 > > change of party > > mid-dialog. > >=20 > > I don't think we can merge them. There was no consensus on=20 > > the response > > identity draft. The following views have been expressed: > > - that it does not provide any benefit; > > - that the response identity problem cannot be solved, and=20 > > that the approach > > taken in the connected-identity draft is the best that can be=20 > > achieved. > >=20 > > If and when there is consensus on a response identity=20 > > solution, then we > > could consider whether it would be appropriate to merge the=20 > > two, but that is > > not the case at present. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Rocky Wang [mailto:rocky.wang@huawei.com] > > > Sent: 21 March 2006 19:50 > > > To: sip@ietf.org > > > Subject: [Sip] draft-cao-sip-response-identity-00 and > > > draft-elwell-sip-connected-identity-01 > > >=20 > > >=20 > > > Both of draft-cao-sip-response-identity-00 and > > > draft-elwell-sip-connected-identity-01 have been disscussed=20 > > in today's=20 > > > SIP session. I found they two can be merged into one. > > > The first one is a common requirement to return back the identity = > > > identifier. It can be used in both successful responses,=20 > > but also in=20 > > > provisiional, redirect and failure responses, but the 2nd=20 > > one is just=20 > > > used for 18X and 2XX response for INVITE (maybe also some=20 > > other type=20 > > > requests). > > > As I considered, the 2nd one is just a sub-set case of the=20 > > first one.=20 > > > Can merge the 2nd one into the 1st one? Or merge the=20 > requirement of=20 > > > the 1st into the last. > > >=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 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 >=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 Mar 23 02:37:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMKMa-0007V3-BC; Thu, 23 Mar 2006 02:36:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMKMY-0007Ut-NE for sip@ietf.org; Thu, 23 Mar 2006 02:36:06 -0500 Received: from smtp5.indiatimes.com ([203.199.93.15] helo=WS0005.indiatimes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMKMV-00042s-Rk for sip@ietf.org; Thu, 23 Mar 2006 02:36:06 -0500 Received: from 192.168.57.15 (a2 [192.168.57.22]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id MAA26770; Thu, 23 Mar 2006 12:27:34 +0530 From: "thejeswara reddy" Message-Id: <200603230657.MAA26770@WS0005.indiatimes.com> To: "Drage Keith Keith", Subject: Re: [Sip] draft-ietf-sip-fork-loop-fix Date: Thu, 23 Mar 2006 13:04:04 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thejeswara reddy List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, how to detect loops caused by spirals of call forwarding for example.. Thejeswara Reddy.P theja_reddy@indiatimes.com "Drage, Keith (Keith)" wrote: (as chair) The face-to-face sip session in ietf 65 identified that draft-ietf-sip-fork-loop-fix is ready as follows. WGLC/Publish this draft at current scope (loop detection only) Continue discussions on other potential improvements as separate efforts Robert will update the draft for resubmission as -01 early next week with the following changes (plus some nit fixes): change 1: SHOULD use 3261 loop detection will change to MAY change 2: branches to connections created using the outbound mechanism won't count towards requiring loop detection. That is, loop detection will be MUST if retargetting to more than one branch that is not a connection established with outbound. If any members of the WG believe that this draft, with the identified revisions, is not ready to move to WGLC, then please identify this to the list, giving appropriate reasons for your opinion. Additionally, if there are any NITS or other issues you have noticed that need fixing, then please send them quickly to the list or the authors as appropriate in order that the version going for WGLC includes as many fixes as possible. regards Keith, Dean Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip Get Your Private, Free E-mail from Indiatimes at http://infinite.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsa hara.indiatimes.com and Bid Now! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 03:29:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMLAm-00027x-7g; Thu, 23 Mar 2006 03:28:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMLAk-00027s-2z for sip@ietf.org; Thu, 23 Mar 2006 03:27:58 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMLAh-0006LU-J8 for sip@ietf.org; Thu, 23 Mar 2006 03:27:58 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k2N8RVE2004934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Mar 2006 09:27:31 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k2N8RPQm024261; Thu, 23 Mar 2006 09:27:25 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k2N8RKJX024260; Thu, 23 Mar 2006 09:27:20 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f From: Hans Persson To: sip@ietf.org, fluffy@cisco.com, rohan@ekabal.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Thu, 23 Mar 2006 09:27:18 +0100 Message-Id: <1143102439.22426.14.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Thu, 23 Mar 2006 09:27:31 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Subject: [Sip] Comments and nits on draft-ietf-sip-outbound-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 sent various nits on outbound-02 a few days ago, but apparently too late to make it into -03. I have gone through the (rather few) changes between -02 and -03 and compared to my comments to -02. Here is an updated list of comments and nits. A few things that aren't clear to me: Section 3.3, second paragraph: Shouldn't "two" on line two be "multiple" or something like that? The rest of the paragraph talks about "two of the physical hosts" and things like that, implying the presence of more than two. Another option is that the text should be something like "two logical hosts" to differentiate it from "physical hosts" later. Section 4.3.2: The sentence starting with "For TLS protocols" should be taken out and shot. I *think* changing "in the next hop URI MUST match one" to "in the next hop URI matches one" is what you want. Section 4.5, second paragraph: The base time is set to 90 seconds here, but in the next paragraph it is 60 seconds. Editorial nits: Section 1, first paragraph: Remove the "the" starting line three. "Connection to the UA" -> "Connections to the UA". Section 1, last paragraph: "Since," -> "Since". "keep alive" -> "keep-alive" (this applies to lots of places throughout the text). Section 2.1. "flow" definition should be "Flow". Colon missing after outbound-proxy-set definition. Section 3: Add comma after "redundancy". Section 3.2, second paragraph: Add "which" after "reg-id parameter". Section 3.3, second paragraph: "the two connection" -> "the two connections". fourth paragraph: Move "approach" to before the parenthesis for better readability. Section 3.4: It seems to be the idea that "Edge Proxy" is to be capitalized, but starting here there are several instances where this is not the case. Section 3.5, "per connection" -> "per-connection". Section 4.1, first paragraph: "cylces" -> "cycles". Section 4.2, first paragraph: Sentence two starts with "The" but it would be better with "This". Section 4.3.1: "When an UA" -> "When a UA". Section 4.3.2: "non TLS" -> "non-TLS". Remove comma after "to this IP address". Section 4.4, second paragraph: "UDP based" -> "UDP-based". "TCP based" - > "TCP-based". Note: Insert "make" before "the keep-alive" and "upper bound" after "120 seconds". Section 4.5, second paragraph: Insert "the" before "power of the number". Section 5.2, Algorithm 1: Change "This results in an approximately 16 octet identifier." to "This results in an identifier approximately 16 octets long." Algorithm 2: "20 byte" -> "20-octet". "The concatenation of the HMAC and S are" -> "The concatenation of the HMAC and S is". "32 octet" -> "32- octet". Section 5.3, Algorithm 2: Remove the comma after "flow token" and put it after "URI". Insert "that" after "checking". Section 6.1, heading: "Register" -> "REGISTER". Third paragraph: Remove the first comma. Section 7, heading: "UAS" -> "UASs". First paragraph: "register" -> "REGISTER". Section 8, last-but-one paragraph: Remove duplicated and misspelled "seams". Section 10.1, first paragraph: Spurious space after reference. Section 10.2, first paragraph: Ditto. Section 10.3, Description: Change "A Registrar places this option-tag in a Supported header to communicate to the registering User Agent the Registrars support for this extension." to "A Registrar places this option-tag in a Supported header to communicate the Registrar's support for this extension to the registering User Agent." Section 11, third paragraph: "route" -> "Route". Fourth paragraph: "route header" -> "Route header". "path header" -> "Path header". Section 12, item 4: Insert "a" before "connection". Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 08:21:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMPj4-0008Tn-7x; Thu, 23 Mar 2006 08:19:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMPj2-0008Ti-Fa for sip@ietf.org; Thu, 23 Mar 2006 08:19:40 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMPj1-0001XV-7F for sip@ietf.org; Thu, 23 Mar 2006 08:19:40 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id k2NDJc3Z025100; Thu, 23 Mar 2006 06:19:38 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on location conveyance draft Date: Thu, 23 Mar 2006 06:19:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZL8H4R86DD5YbOR8u/Me03TiHeAQBNJMwgADzRf9AAGPbnMA== From: "Jean-Francois Mule" To: "McCalmont, Patti" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Patti wrote: > I would like to make an additional comment on the requirement that > pertains to disabling location. >=20 > A UAC MUST be prevented from disabling conveyance of location > for > an emergency call if local jurisdiction (laws of that particular > country) requires it. >=20 > Rational: UACs must abide by regulations for emergency calls as > dictated > by the local laws (where the emergency event occurs). I don't believe this requirement applies to UACs. End-users, service = providers, and enterprises abide the local regulations, not UACs or = devices. Jean-Fran=E7ois _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 08:32:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMPtL-0000RZ-Th; Thu, 23 Mar 2006 08:30:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMPtK-0000RU-Ny for sip@ietf.org; Thu, 23 Mar 2006 08:30:18 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMPtH-0001xU-7D for sip@ietf.org; Thu, 23 Mar 2006 08:30:18 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWL00I011DS37@siemenscomms.co.uk> for sip@ietf.org; Thu, 23 Mar 2006 13:27:28 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWL00H0O1DSWS@siemenscomms.co.uk>; Thu, 23 Mar 2006 13:27:28 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Mar 2006 13:30:13 +0000 Content-return: allowed Date: Thu, 23 Mar 2006 13:29:49 +0000 From: "Elwell, John" Subject: RE: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 To: Feng Cao Message-id: <50B1CBA96870A34799A506B2313F2667087A2D4B@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 1.1 (+) 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: , Errors-To: sip-bounces@ietf.org Feng, See below. John > -----Original Message----- > From: Feng Cao [mailto:fcao@cisco.com] > Sent: 22 March 2006 21:01 > To: Elwell, John > Cc: Rocky Wang; sip@ietf.org > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > draft-elwell-sip -connected-identity-01 > > > Because connected-id is revealed in the mid-dialog, there are some > scenarios that are not covered by connected-identity draft. > > In general, I agreed with Rocky that the mid-dialog update can be > easily convered or embeded into the sip identity draft by Jon and > Cullen. I don't see the need of another new draft for it. [JRE] The identity draft has already been approved. > > Some useful scenarios for response identity inside response messages > had been listed for discussion: > 1. disclose the response identity for non-dialog session. > 2. reveal the proxy's identity as the responder for some response > codes, such as provisiional, redirect and failure responses. > This will help the callers to make decisions. > 3. prevent the identity spoofing as early as possible. In some cases, > it is too late to be notifies of the response identity after the > dialogs are established. [JRE] Yes, I understand these additional uses that are not covered by the connected-identity draft. I look forward to reviewing further drafts that address the problems raised during the meeting. > > --Feng > > > On Wed, 22 Mar 2006, Elwell, John wrote: > > Rocky, > > > > The connected-identity draft already gives two examples why > a mid-dialog > > change would be needed: PSTN gateway and B2BUA. > > > > We could define a new header field for response identity if > this can be > > justified, but it would not be secure. I think the > consensus yesterday was > > to move forward with connected-identity and consider > separately whether > > response identity is achievable in a way that is secure as > well as adding > > some value in certain use cases. > > > > John > > > > > >> -----Original Message----- > >> From: Rocky Wang [mailto:rocky.wang@huawei.com] > >> Sent: 22 March 2006 14:44 > >> To: Elwell, John; sip@ietf.org > >> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > >> draft-elwell-sip-connected-identity-01 > >> > >> As my opinion, they two just need take the responser > >> identifier in the > >> response messages. We must consider and resolve all the > >> problem include the > >> security problems in both cases. > >> If you want to indicate a change of party mid-dialog, you > can use some > >> mid-dialog method to do it, as I considered, just like UPDATE > >> and re-INVITE. > >> That's not so difficult in use of exist mechanism. But can > >> you please give > >> me an application case of the usage of mid-dialog entity identifier > >> indication. > >> > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens.com] > >> Sent: Tuesday, March 21, 2006 11:44 PM > >> To: Rocky Wang; sip@ietf.org > >> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > >> draft-elwell-sip-connected-identity-01 > >> > >> Rocky, > >> > >> The connected-identity draft is not a subset of the response > >> identity draft. > >> The response identity draft cannot be used to indicate a > >> change of party > >> mid-dialog. > >> > >> I don't think we can merge them. There was no consensus on > >> the response > >> identity draft. The following views have been expressed: > >> - that it does not provide any benefit; > >> - that the response identity problem cannot be solved, and > >> that the approach > >> taken in the connected-identity draft is the best that can be > >> achieved. > >> > >> If and when there is consensus on a response identity > >> solution, then we > >> could consider whether it would be appropriate to merge the > >> two, but that is > >> not the case at present. > >> > >> John > >> > >>> -----Original Message----- > >>> From: Rocky Wang [mailto:rocky.wang@huawei.com] > >>> Sent: 21 March 2006 19:50 > >>> To: sip@ietf.org > >>> Subject: [Sip] draft-cao-sip-response-identity-00 and > >>> draft-elwell-sip-connected-identity-01 > >>> > >>> > >>> Both of draft-cao-sip-response-identity-00 and > >>> draft-elwell-sip-connected-identity-01 have been disscussed > >> in today's > >>> SIP session. I found they two can be merged into one. > >>> The first one is a common requirement to return back the identity > >>> identifier. It can be used in both successful responses, > >> but also in > >>> provisiional, redirect and failure responses, but the 2nd > >> one is just > >>> used for 18X and 2XX response for INVITE (maybe also some > >> other type > >>> requests). > >>> As I considered, the 2nd one is just a sub-set case of the > >> first one. > >>> Can merge the 2nd one into the 1st one? Or merge the > requirement of > >>> the 1st into the last. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use > >>> sip-implementors@cs.columbia.edu for questions on current sip Use > >>> sipping@ietf.org for new developments on the application of sip > >>> > >> > >> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 08:35:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMPwn-0002Sf-S5; Thu, 23 Mar 2006 08:33:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMPwm-0002Lw-Bw for sip@ietf.org; Thu, 23 Mar 2006 08:33:52 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMPwg-0002Ao-Qi for sip@ietf.org; Thu, 23 Mar 2006 08:33:52 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWL00I011JNV2@siemenscomms.co.uk> for sip@ietf.org; Thu, 23 Mar 2006 13:30:59 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWL00H7Z1JMWS@siemenscomms.co.uk>; Thu, 23 Mar 2006 13:30:58 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Mar 2006 13:33:43 +0000 Content-return: allowed Date: Thu, 23 Mar 2006 13:33:17 +0000 From: "Elwell, John" Subject: RE: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 To: "Jesske, R" , rocky.wang@huawei.com, sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667087A2D60@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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 Roland, Yes, I agree that interworking with PSTN is not quite so straight = forward with this approach. Personally for networks where PAI is appropriate = such as TISPAN I see no objection to using it in a response, provided the = asserting entity has had some way of authenticating the connected UA (e.g., by = virtue of the response having been received on a TLS connection on which the = UA has already been authenticated). However, there are some ambiguities in the = PAI RFC and past discussions on the list on this topic have led to the = opinion from some experts that it is not intended for use in responses. Note that Feng's proposal has the same limitation - an authentication service cannot provide a cryptographic authentication of response = identity unless the UAS is reached by a TLS connection over which the UA has = already been authenticated. The connected-identity draft gets around this = problem. John=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > Sent: 23 March 2006 06:49 > To: Elwell, John; rocky.wang@huawei.com; sip@ietf.org > Subject: AW: [Sip] draft-cao-sip-response-identity-00 and=20 > draft-elwell-sip -connected-identity-01 >=20 > Dear John, > looking on your draft, I see the problem with the=20 > interworking to the PSTN/ISDN network. > With sending a 200OK in backward direction the PSTN Gateway=20 > send an Answer in ISUP. So there is no chance to send an=20 > second Answer because the call is already switched through. > So in such a case new PSTN GWs are needed to wait until the=20 > UPDATE is received. >=20 > You said that a Header is not secure. What we in TISPAN need=20 > is a secure connected ID and a second from the user send=20 > connected ID that must not be secure. > Like as you indicate with your connected ID and the changed=20 > From header. >=20 > Sorry for asking this question again > Why can we not use the P-Asserted-Identity in Responses? It=20 > is also a secure identity. > And add only a new header like a connected-From header. Or is=20 > this not generic enough? >=20 > Best Regards >=20 > Roland >=20 >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > > Gesendet: Mittwoch, 22. M=E4rz 2006 19:45 > > An: Rocky Wang; sip@ietf.org > > Betreff: RE: [Sip] draft-cao-sip-response-identity-00 and=20 > > draft-elwell-sip -connected-identity-01 > >=20 > >=20 > > Rocky, > >=20 > > The connected-identity draft already gives two examples why a=20 > > mid-dialog > > change would be needed: PSTN gateway and B2BUA. > >=20 > > We could define a new header field for response identity if=20 > > this can be > > justified, but it would not be secure. I think the consensus=20 > > yesterday was > > to move forward with connected-identity and consider=20 > > separately whether > > response identity is achievable in a way that is secure as=20 > > well as adding > > some value in certain use cases. > >=20 > > John > > =20 > >=20 > > > -----Original Message----- > > > From: Rocky Wang [mailto:rocky.wang@huawei.com]=20 > > > Sent: 22 March 2006 14:44 > > > To: Elwell, John; sip@ietf.org > > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and=20 > > > draft-elwell-sip-connected-identity-01 > > >=20 > > > As my opinion, they two just need take the responser=20 > > > identifier in the > > > response messages. We must consider and resolve all the=20 > > > problem include the > > > security problems in both cases. > > > If you want to indicate a change of party mid-dialog, you=20 > > can use some > > > mid-dialog method to do it, as I considered, just like UPDATE=20 > > > and re-INVITE. > > > That's not so difficult in use of exist mechanism. But can=20 > > > you please give > > > me an application case of the usage of mid-dialog entity=20 > identifier > > > indication. > > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > > > Sent: Tuesday, March 21, 2006 11:44 PM > > > To: Rocky Wang; sip@ietf.org > > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > > > draft-elwell-sip-connected-identity-01 > > >=20 > > > Rocky, > > >=20 > > > The connected-identity draft is not a subset of the response=20 > > > identity draft. > > > The response identity draft cannot be used to indicate a=20 > > > change of party > > > mid-dialog. > > >=20 > > > I don't think we can merge them. There was no consensus on=20 > > > the response > > > identity draft. The following views have been expressed: > > > - that it does not provide any benefit; > > > - that the response identity problem cannot be solved, and=20 > > > that the approach > > > taken in the connected-identity draft is the best that can be=20 > > > achieved. > > >=20 > > > If and when there is consensus on a response identity=20 > > > solution, then we > > > could consider whether it would be appropriate to merge the=20 > > > two, but that is > > > not the case at present. > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: Rocky Wang [mailto:rocky.wang@huawei.com] > > > > Sent: 21 March 2006 19:50 > > > > To: sip@ietf.org > > > > Subject: [Sip] draft-cao-sip-response-identity-00 and > > > > draft-elwell-sip-connected-identity-01 > > > >=20 > > > >=20 > > > > Both of draft-cao-sip-response-identity-00 and > > > > draft-elwell-sip-connected-identity-01 have been disscussed=20 > > > in today's=20 > > > > SIP session. I found they two can be merged into one. > > > > The first one is a common requirement to return back=20 > the identity=20 > > > > identifier. It can be used in both successful responses,=20 > > > but also in=20 > > > > provisiional, redirect and failure responses, but the 2nd=20 > > > one is just=20 > > > > used for 18X and 2XX response for INVITE (maybe also some=20 > > > other type=20 > > > > requests). > > > > As I considered, the 2nd one is just a sub-set case of the=20 > > > first one.=20 > > > > Can merge the 2nd one into the 1st one? Or merge the=20 > > requirement of=20 > > > > the 1st into the last. > > > >=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 > >=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 Mar 23 08:35:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMPwq-0002Wf-Os; Thu, 23 Mar 2006 08:33:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMPwp-0002Uf-Rj for sip@ietf.org; Thu, 23 Mar 2006 08:33:55 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMPwm-0002Ao-Eh for sip@ietf.org; Thu, 23 Mar 2006 08:33:55 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWL00I011JNV2@siemenscomms.co.uk> for sip@ietf.org; Thu, 23 Mar 2006 13:31:00 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWL00H7Z1JMWS@siemenscomms.co.uk>; Thu, 23 Mar 2006 13:30:58 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Mar 2006 13:33:43 +0000 Content-return: allowed Date: Thu, 23 Mar 2006 13:33:32 +0000 From: "Elwell, John" Subject: RE: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 To: Rocky Wang , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667087A2D62@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 1.1 (+) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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 Rocky, See below. John > -----Original Message----- > From: Rocky Wang [mailto:rocky.wang@huawei.com] > Sent: 22 March 2006 23:41 > To: Elwell, John; sip@ietf.org > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > draft-elwell-sip-connected-identity-01 > > I agree with you that there are some requirements to convey > the changed > identifier. But I think UPDATE and re-INVITE can be used to > do so, that is > no need to create a 2nd solution. [JRE] That is exactly what the connected-identity draft does - UPDATE or re-INVITE (or any other mid-dialog request if being sent for some other reason). It needs something to update RFC 3261 and specify this. This is why we need the connected-identity draft. > Apart from the mid-dialog requiements, the Connect-URI can be > considered as > a sub-set of the response identifier. Today we are discussing about > conveying the connected URI that return the response, > tomorrow, maybe we > must re-consider how to convey the identifier which return > responses and > then we must do the same thing again, including the security > and some other > problems. [JRE] I cant' parse the above paragraph. > What I want to say is that the two drafts can be merged > easily from the > requirement and expected solution aspects because they are > overlapped with > each other, and we should do so as my owner opinion. [JRE] The problem at present is that we have a strong WG opinion to proceed with connected-ID, but we do not have any consensus on response-ID, since that requires further work. What we need to do is to revise the response-identity work to take account of comments received in the meeting and get WG consensus on a technical solution. Until that has been done it is premature to talk about merger of documents. > > Rocky Wang > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Wednesday, March 22, 2006 12:45 PM > > To: Rocky Wang; sip@ietf.org > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > > draft-elwell-sip-connected-identity-01 > > > > Rocky, > > > > The connected-identity draft already gives two examples why a > > mid-dialog change would be needed: PSTN gateway and B2BUA. > > > > We could define a new header field for response identity if > > this can be justified, but it would not be secure. I think > > the consensus yesterday was to move forward with > > connected-identity and consider separately whether response > > identity is achievable in a way that is secure as well as > > adding some value in certain use cases. > > > > John > > > > > > > -----Original Message----- > > > From: Rocky Wang [mailto:rocky.wang@huawei.com] > > > Sent: 22 March 2006 14:44 > > > To: Elwell, John; sip@ietf.org > > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > > > draft-elwell-sip-connected-identity-01 > > > > > > As my opinion, they two just need take the responser > identifier in > > > the response messages. We must consider and resolve all > the problem > > > include the security problems in both cases. > > > If you want to indicate a change of party mid-dialog, you > > can use some > > > mid-dialog method to do it, as I considered, just like UPDATE and > > > re-INVITE. > > > That's not so difficult in use of exist mechanism. But can > > you please > > > give me an application case of the usage of mid-dialog entity > > > identifier indication. > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Tuesday, March 21, 2006 11:44 PM > > > To: Rocky Wang; sip@ietf.org > > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > > > draft-elwell-sip-connected-identity-01 > > > > > > Rocky, > > > > > > The connected-identity draft is not a subset of the > > response identity > > > draft. > > > The response identity draft cannot be used to indicate a > change of > > > party mid-dialog. > > > > > > I don't think we can merge them. There was no consensus on the > > > response identity draft. The following views have been expressed: > > > - that it does not provide any benefit; > > > - that the response identity problem cannot be solved, > and that the > > > approach taken in the connected-identity draft is the best > > that can be > > > achieved. > > > > > > If and when there is consensus on a response identity > > solution, then > > > we could consider whether it would be appropriate to > merge the two, > > > but that is not the case at present. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Rocky Wang [mailto:rocky.wang@huawei.com] > > > > Sent: 21 March 2006 19:50 > > > > To: sip@ietf.org > > > > Subject: [Sip] draft-cao-sip-response-identity-00 and > > > > draft-elwell-sip-connected-identity-01 > > > > > > > > > > > > Both of draft-cao-sip-response-identity-00 and > > > > draft-elwell-sip-connected-identity-01 have been disscussed > > > in today's > > > > SIP session. I found they two can be merged into one. > > > > The first one is a common requirement to return back > the identity > > > > identifier. It can be used in both successful responses, > > > but also in > > > > provisiional, redirect and failure responses, but the 2nd > > > one is just > > > > used for 18X and 2XX response for INVITE (maybe also some > > > other type > > > > requests). > > > > As I considered, the 2nd one is just a sub-set case of the > > > first one. > > > > Can merge the 2nd one into the 1st one? Or merge the > > requirement of > > > > the 1st into the last. > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on > current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 09:57:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRE4-0005NB-F2; Thu, 23 Mar 2006 09:55:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRE3-0005N3-E6 for sip@ietf.org; Thu, 23 Mar 2006 09:55:47 -0500 Received: from ns2.sccx.com ([209.108.197.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMRE2-0005hF-4P for sip@ietf.org; Thu, 23 Mar 2006 09:55:47 -0500 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] comments on location conveyance draft X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 23 Mar 2006 08:55:40 -0600 Message-ID: <422D410BD61FC04185076AD99AA7207A01771F76@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZL8H4R86DD5YbOR8u/Me03TiHeAQBNJMwgADzRf9AAGPbnMAADUgUw From: "McCalmont, Patti" To: "Jean-Francois Mule" X-OriginalArrivalTime: 23 Mar 2006 14:55:42.0817 (UTC) FILETIME=[DB961510:01C64E89] 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 If the UAC is the entity that is directly requesting emergency = assistance, then it too should abide by local regulations. I do realize = that in most cases there will be some other entity, e.g. service = provider, that will interact but if the location isn't there, how can = local regulations be abided to? Patti -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Thursday, March 23, 2006 7:20 AM To: McCalmont, Patti Cc: sip@ietf.org Subject: RE: [Sip] comments on location conveyance draft Patti wrote: > I would like to make an additional comment on the requirement that > pertains to disabling location. >=20 > A UAC MUST be prevented from disabling conveyance of location > for > an emergency call if local jurisdiction (laws of that particular > country) requires it. >=20 > Rational: UACs must abide by regulations for emergency calls as > dictated > by the local laws (where the emergency event occurs). I don't believe this requirement applies to UACs. End-users, service = providers, and enterprises abide the local regulations, not UACs or = devices. Jean-Fran=E7ois _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 10:11:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRR6-0000Iq-7f; Thu, 23 Mar 2006 10:09:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRR5-0000Il-04 for sip@ietf.org; Thu, 23 Mar 2006 10:09:15 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMRR3-0006ZM-O0 for sip@ietf.org; Thu, 23 Mar 2006 10:09:14 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 Mar 2006 10:09:14 -0500 X-IronPort-AV: i="4.03,123,1141621200"; d="scan'208"; a="84801513:sNHT30821692" 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 k2NF9CWc011464; Thu, 23 Mar 2006 10:09:13 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Mar 2006 10:09:12 -0500 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] comments on location conveyance draft Date: Thu, 23 Mar 2006 10:09:11 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3013D88C9@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZL8H4R86DD5YbOR8u/Me03TiHeAQBNJMwgADzRf9AAGPbnMAADUgUwAACEsLA= From: "Michael Hammer \(mhammer\)" To: "McCalmont, Patti" , "Jean-Francois Mule" X-OriginalArrivalTime: 23 Mar 2006 15:09:12.0701 (UTC) FILETIME=[BE5092D0:01C64E8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 And if the "local" totalitarian regulation says that phones should have = location tracking on all the time, should the phone whose home is in = some non-totalitarian region obey that? Think mobility. Mike > -----Original Message----- > From: McCalmont, Patti [mailto:Patti.McCalmont@intrado.com]=20 > Sent: Thursday, March 23, 2006 9:56 AM > To: Jean-Francois Mule > Cc: sip@ietf.org > Subject: RE: [Sip] comments on location conveyance draft >=20 > If the UAC is the entity that is directly requesting=20 > emergency assistance, then it too should abide by local=20 > regulations. I do realize that in most cases there will be=20 > some other entity, e.g. service provider, that will interact=20 > but if the location isn't there, how can local regulations be=20 > abided to? >=20 > Patti >=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Thursday, March 23, 2006 7:20 AM > To: McCalmont, Patti > Cc: sip@ietf.org > Subject: RE: [Sip] comments on location conveyance draft >=20 > Patti wrote: > > I would like to make an additional comment on the requirement that=20 > > pertains to disabling location. > >=20 > > A UAC MUST be prevented from disabling conveyance of location=20 > > for an emergency call if local jurisdiction (laws of that particular > > country) requires it. > >=20 > > Rational: UACs must abide by regulations for emergency calls as=20 > > dictated by the local laws (where the emergency event occurs). >=20 > I don't believe this requirement applies to UACs. End-users,=20 > service providers, and enterprises abide the local=20 > regulations, not UACs or devices. >=20 > Jean-Fran=E7ois >=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 Mar 23 10:18:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRY2-0006uE-7B; Thu, 23 Mar 2006 10:16:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRY0-0006tz-4R for sip@ietf.org; Thu, 23 Mar 2006 10:16:24 -0500 Received: from [209.108.197.61] (helo=ns1.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMRXz-0007Hf-P7 for sip@ietf.org; Thu, 23 Mar 2006 10:16:24 -0500 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] comments on location conveyance draft X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 23 Mar 2006 09:16:16 -0600 Message-ID: <422D410BD61FC04185076AD99AA7207A01771F8F@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZL8H4R86DD5YbOR8u/Me03TiHeAQBNJMwgADzRf9AAGPbnMAADUgUwAACEsLAAABspQA== From: "McCalmont, Patti" To: "Michael Hammer \(mhammer\)" , "Jean-Francois Mule" X-OriginalArrivalTime: 23 Mar 2006 15:16:18.0457 (UTC) FILETIME=[BC15C890:01C64E8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 The issue is, if you are making an emergency call and in a country that = requires your location so that it can dispatch responders to help you, = then it is necessary for location to be conveyed to the PSAP. If not by = the UAC, then somewhere in the network prior to the call reaching the = PSAP, so I don't have an issue if location is obtained by reference or = the UACs service provider. If the UAC is the holder of the location and = there is no other entity in the path that will provide it, then it puts = the responsibility on the UAC. Patti -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Thursday, March 23, 2006 9:09 AM To: McCalmont, Patti; Jean-Francois Mule Cc: sip@ietf.org Subject: RE: [Sip] comments on location conveyance draft And if the "local" totalitarian regulation says that phones should have = location tracking on all the time, should the phone whose home is in = some non-totalitarian region obey that? Think mobility. Mike > -----Original Message----- > From: McCalmont, Patti [mailto:Patti.McCalmont@intrado.com]=20 > Sent: Thursday, March 23, 2006 9:56 AM > To: Jean-Francois Mule > Cc: sip@ietf.org > Subject: RE: [Sip] comments on location conveyance draft >=20 > If the UAC is the entity that is directly requesting=20 > emergency assistance, then it too should abide by local=20 > regulations. I do realize that in most cases there will be=20 > some other entity, e.g. service provider, that will interact=20 > but if the location isn't there, how can local regulations be=20 > abided to? >=20 > Patti >=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Thursday, March 23, 2006 7:20 AM > To: McCalmont, Patti > Cc: sip@ietf.org > Subject: RE: [Sip] comments on location conveyance draft >=20 > Patti wrote: > > I would like to make an additional comment on the requirement that=20 > > pertains to disabling location. > >=20 > > A UAC MUST be prevented from disabling conveyance of location=20 > > for an emergency call if local jurisdiction (laws of that particular > > country) requires it. > >=20 > > Rational: UACs must abide by regulations for emergency calls as=20 > > dictated by the local laws (where the emergency event occurs). >=20 > I don't believe this requirement applies to UACs. End-users,=20 > service providers, and enterprises abide the local=20 > regulations, not UACs or devices. >=20 > Jean-Fran=E7ois >=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 Mar 23 10:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRru-0001ih-Dm; Thu, 23 Mar 2006 10:36:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRrt-0001hc-4P for sip@ietf.org; Thu, 23 Mar 2006 10:36:57 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMRrr-0008Ul-RH for sip@ietf.org; Thu, 23 Mar 2006 10:36:57 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2NFahrc013800; Thu, 23 Mar 2006 09:36:44 -0600 (CST) Received: from [135.244.0.175] (vkg.lra2.lucent.com [135.244.0.175]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2NFahB15276; Thu, 23 Mar 2006 09:36:43 -0600 (CST) Message-ID: <4422C08C.7090306@lucent.com> Date: Thu, 23 Mar 2006 09:36:44 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rocky Wang Subject: Re: [Sip] Some doubts about draft-ietf-sip-connect-reuse-05 References: <000601c64df1$bc52d500$02848182@china.huawei.com> In-Reply-To: <000601c64df1$bc52d500$02848182@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Rocky Wang wrote: > The following sentense is from the client behavior part of the draft. > Maybe I missed something. > And furthermore, it MUST reuse the > connection when subsequent requests in the same or different > transactions are destined to the same resolved address. > > Whether or not to allow an aliased connection ultimately depends on > the recepient of the request. Thus, clients MUST NOT assume that the > acceptance of a request by a server automatically enables connection > aliasing. They MUST continue receiving requests on their default > port. Rocky: I will attempt to clarify this in the next rev. All the above paragraphs are saying is (a) when a client establishes an alias with the downstream server, it must use the aliased connection on subsequent requests, and (b) since the alias mechanism does not have a negotiation process, the client cannot really be sure that the server accepted the alias and will send subsequent requests in the backwards direction over the aliased connection. Thus, it must be prepared to receive new requests from the same downstream server over the default port. > The following part is also from the client behavior part of the > draft. Please help me to check it. > > The implications of placing an "alias" parameter in the topmost Via > header of a request must be understood by the client. Specifically, > this means that the client MUST keep the connection open for as long > as the resources on the host operating system allow it to, and that > it MUST accept requests over this connection -- as opposed to a > default listening port -- from its downstream peer. OK; maybe this needs some more explanation in the next rev as well. This goes back to the discussion we had in the previous email in this thread. The normative statements simply state that the client must keep the connection alive for as long as it can. Reclamation of the connection should be done based on some heuristics, but at the very least, the connection to the same downstream server should not be opened and closed with regularity if the benefits of connection reuse are to be realized. I will add some more explanatory text in the next rev. Thank you for your comments. Regards, - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 23 11:09:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSLf-0002GG-AC; Thu, 23 Mar 2006 11:07:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSLd-0002GB-LM for sip@ietf.org; Thu, 23 Mar 2006 11:07:41 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMSLc-0001RM-D3 for sip@ietf.org; Thu, 23 Mar 2006 11:07:41 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id k2NG7ctB001317; Thu, 23 Mar 2006 09:07:38 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on location conveyance draft Date: Thu, 23 Mar 2006 09:07:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZL8H4R86DD5YbOR8u/Me03TiHeAQBNJMwgADzRf9AAGPbnMAADUgUwAACEsLAAABspQAABxY1Q From: "Jean-Francois Mule" To: "McCalmont, Patti" , "Michael Hammer (mhammer)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Patti, I may understand the motivations, but again, I don't believe any = formal requirements around the applicability of to-be-defined, local, or = country-specific laws should be in the SIP location conveyance draft. Jean-Fran=E7ois You wrote: > The issue is, if you are making an emergency call and in a country > that requires your location so that it can dispatch responders to help > you, then it is necessary for location to be conveyed to the PSAP. If > not by the UAC, then somewhere in the network prior to the call > reaching the PSAP, so I don't have an issue if location is obtained by > reference or the UACs service provider. If the UAC is the holder of > the location and there is no other entity in the path that will > provide it, then it puts the responsibility on the UAC. >=20 > Patti _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 11:19:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSUt-0003IN-UC; Thu, 23 Mar 2006 11:17:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSUr-0003II-GM for sip@ietf.org; Thu, 23 Mar 2006 11:17:13 -0500 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 1FMSUq-0001fi-SV for sip@ietf.org; Thu, 23 Mar 2006 11:17:13 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2006 08:17:12 -0800 X-IronPort-AV: i="4.03,123,1141632000"; d="scan'208"; a="419578603:sNHT34462900" Received: from billybong.cisco.com (billybong.cisco.com [171.71.163.234]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2NGHBw2006744; Thu, 23 Mar 2006 08:17:12 -0800 (PST) Date: Thu, 23 Mar 2006 08:17:11 -0800 (PST) From: Feng Cao To: Shida Schubert Subject: Re: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip-connected-identity-01 In-Reply-To: <4421F997.8090505@ntt-at.com> Message-ID: References: <003401c64e0a$332e4e30$02848182@china.huawei.com> <4421F997.8090505@ntt-at.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: sip@ietf.org, "'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 Hi Shida, Your comments reflected many offline discussions we had with some folks. They can be summarized into the following three questions. Then the logic relationships among them can be understood and the scope can be defined. Q1. provide the mechanism to disclose response identity (and integrity protection) in all call scenarios. That is the exact scope our draft tried to address. As you pointed out, there are issues about it. Please see the following questions. Q2. provide the secure authentication and authorization mechanism for response We did realize this problem. We submitted another draft to address this question, it is available at http://www.ietf.org/internet-drafts/draft-cao-sip-response-auth-01.txt. We had received some feedbacks about it outside this list. The consensus with some folks before the meeting is to discuss Q1 first and see if we can make progress. I think it is reasonable to separate Q1 and Q2, as the scopes and the solutions are different. Frankly, I expected this question to be raised, as you and a few other folks did either in this list and in private discussions. Q3. provide the mechanism to understand why that responder is reached. This is a very interesting (and hard) problem about SIP request deliverary. First, this should be out of scope about response identity, even though the answer can be helpful. Second, it is not among SIP WG deliverables? Hope this summary can be helpful for further discussions. Thanks, --Feng On Wed, 22 Mar 2006, Shida Schubert wrote: > > Hi Rocky; > > Why do you want the response identity so bad? > - As I understand there are two issues, response identity is trying to > solve. > Issue 1. Who am I really connected to and is it really who it claims it is? > - Connected Identity solves this problem by allowing the changes in From > header > field and re-using the SIP-Identity spec. The Connected-Identity spec > is nice > because it reuses what's already there and does not introduce any new > header for > indicating identity. And inherit all the nice traits identity header > provides such as > integrity etc. > - Response Identity tries to provide the same thing by introducing few new > headers > which clutters the header with more Identity related information. Beside > there are > few issues with how one should trust the response-identity(Proxy unable > to authorize > the response etc.). > > Issue 2. Am I connected to foo as a result of routing decision based on my > INVITE? > - Can't really solve the issue with neither of the solution described > above. > > Issue 2 can't be solved by neither of the solution and Issue 1 can be > solved with > Connected Identity without adding any extra identity related header. So I > personally > don't know why you are so persistent with adopting them both? I think > Connected-Identity alone satisfies what the WG wants, but I could be > completely > wrong. > > As for other reason why I don't think they should merge, currently they > propose two > completely different solution to address the same problem yet at different > timing. > > And let's not forget, merging the work would create dependency on each spec > and > results in creating a delays in overall progress. I have been hearing that > WG wants to > resolve Issue 1, in which case delay due to the merge is likely to be > unacceptable. > > Regards > Shida Schubert > > Rocky Wang wrote: >> I agree with you that there are some requirements to convey the changed >> identifier. But I think UPDATE and re-INVITE can be used to do so, that is >> no need to create a 2nd solution. >> Apart from the mid-dialog requiements, the Connect-URI can be considered >> as >> a sub-set of the response identifier. Today we are discussing about >> conveying the connected URI that return the response, tomorrow, maybe we >> must re-consider how to convey the identifier which return responses and >> then we must do the same thing again, including the security and some >> other >> problems. >> What I want to say is that the two drafts can be merged easily from the >> requirement and expected solution aspects because they are overlapped with >> each other, and we should do so as my owner opinion. >> >> Rocky Wang >> >> >> >> > -----Original Message----- >> > From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Wednesday, >> > March 22, 2006 12:45 PM >> > To: Rocky Wang; sip@ietf.org >> > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >> > draft-elwell-sip-connected-identity-01 >> > >> > Rocky, >> > >> > The connected-identity draft already gives two examples why a mid-dialog >> > change would be needed: PSTN gateway and B2BUA. >> > >> > We could define a new header field for response identity if this can be >> > justified, but it would not be secure. I think the consensus yesterday >> > was to move forward with connected-identity and consider separately >> > whether response identity is achievable in a way that is secure as well >> > as adding some value in certain use cases. >> > >> > John >> > >> > >> > >> > > -----Original Message----- >> > > From: Rocky Wang [mailto:rocky.wang@huawei.com] >> > > Sent: 22 March 2006 14:44 >> > > To: Elwell, John; sip@ietf.org >> > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >> > > draft-elwell-sip-connected-identity-01 >> > > >> > > As my opinion, they two just need take the responser identifier in the >> > > response messages. We must consider and resolve all the problem >> > > include the security problems in both cases. >> > > If you want to indicate a change of party mid-dialog, you >> > > >> > can use some >> > >> > > mid-dialog method to do it, as I considered, just like UPDATE and >> > > re-INVITE. >> > > That's not so difficult in use of exist mechanism. But can >> > > >> > you please >> > >> > > give me an application case of the usage of mid-dialog entity >> > > identifier indication. >> > > >> > > -----Original Message----- >> > > From: Elwell, John [mailto:john.elwell@siemens.com] >> > > Sent: Tuesday, March 21, 2006 11:44 PM >> > > To: Rocky Wang; sip@ietf.org >> > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >> > > draft-elwell-sip-connected-identity-01 >> > > >> > > Rocky, >> > > >> > > The connected-identity draft is not a subset of the >> > > >> > response identity >> > >> > > draft. >> > > The response identity draft cannot be used to indicate a change of >> > > party mid-dialog. >> > > >> > > I don't think we can merge them. There was no consensus on the >> > > response identity draft. The following views have been expressed: >> > > - that it does not provide any benefit; >> > > - that the response identity problem cannot be solved, and that the >> > > approach taken in the connected-identity draft is the best >> > > >> > that can be >> > >> > > achieved. >> > > >> > > If and when there is consensus on a response identity >> > > >> > solution, then >> > >> > > we could consider whether it would be appropriate to merge the two, >> > > but that is not the case at present. >> > > >> > > John >> > > >> > > >> > > > -----Original Message----- >> > > > From: Rocky Wang [mailto:rocky.wang@huawei.com] >> > > > Sent: 21 March 2006 19:50 >> > > > To: sip@ietf.org >> > > > Subject: [Sip] draft-cao-sip-response-identity-00 and >> > > > draft-elwell-sip-connected-identity-01 >> > > > >> > > > >> > > > Both of draft-cao-sip-response-identity-00 and >> > > > draft-elwell-sip-connected-identity-01 have been disscussed >> > > > >> > > in today's >> > > >> > > > SIP session. I found they two can be merged into one. >> > > > The first one is a common requirement to return back the identity >> > > > identifier. It can be used in both successful responses, >> > > > >> > > but also in >> > > >> > > > provisiional, redirect and failure responses, but the 2nd >> > > > >> > > one is just >> > > >> > > > used for 18X and 2XX response for INVITE (maybe also some >> > > > >> > > other type >> > > >> > > > requests). >> > > > As I considered, the 2nd one is just a sub-set case of the >> > > > >> > > first one. >> > > >> > > > Can merge the 2nd one into the 1st one? Or merge the >> > > > >> > requirement of >> > >> > > > the 1st into the last. >> > > > >> > > > >> > > > >>>>> _______________________________________________ >> > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > > > This list is for NEW development of the core SIP Protocol Use >> > > > sip-implementors@cs.columbia.edu for questions on current sip Use >> > > > sipping@ietf.org for new developments on the application of sip >> > > > >> > > > >> > > >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> >> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 11:32:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMShx-0000yP-8S; Thu, 23 Mar 2006 11:30:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMShv-0000yK-Oz for sip@ietf.org; Thu, 23 Mar 2006 11:30:43 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMShv-0002D3-7u for sip@ietf.org; Thu, 23 Mar 2006 11:30:43 -0500 Received: from dhcp-wireless-134-205.ietf65.org ([130.129.134.205]) by dns.aliantmedia.net with esmtpa (Exim 4.52) id 1FMShs-0003ve-Ue; Thu, 23 Mar 2006 10:30:42 -0600 Message-ID: <4422CD2B.9010204@ntt-at.com> Date: Thu, 23 Mar 2006 08:30:35 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Feng Cao Subject: Re: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip-connected-identity-01 References: <003401c64e0a$332e4e30$02848182@china.huawei.com> <4421F997.8090505@ntt-at.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.2 (+) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: sip@ietf.org, "'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 Hi Feng; Comments inline.. Feng Cao wrote: > Hi Shida, > > Your comments reflected many offline discussions we had with > some folks. They can be summarized into the following three > questions. Then the logic relationships among them can be understood > and the scope can be defined. > > Q1. provide the mechanism to disclose response identity > (and integrity protection) in all call scenarios. > > That is the exact scope our draft tried to address. As you pointed > out, > there are issues about it. Please see the following questions. > I understand. > Q2. provide the secure authentication and authorization mechanism > for response > > We did realize this problem. We submitted another draft > to address this question, it is available at > http://www.ietf.org/internet-drafts/draft-cao-sip-response-auth-01.txt. > We had received some feedbacks about it outside this list. > > The consensus with some folks before the meeting is to discuss Q1 > first > and see if we can make progress. I think it is reasonable to separate > Q1 and Q2, as the scopes and the solutions are different. > > Frankly, I expected this question to be raised, as you and > a few other folks did either in this list and in private discussions. I read the draft, and it seems like you are re-defining TLS. > > Q3. provide the mechanism to understand why that responder is reached. > > This is a very interesting (and hard) problem about SIP request > deliverary. First, this should be out of scope about response > identity, even though the answer can be helpful. Second, it is not > among SIP WG deliverables? > Okay I thought this was addressed as one of the problem space your draft is trying to solve. I guess, I miss read the draft. My apology. Regards Shida Schubert > Hope this summary can be helpful for further discussions. > > Thanks, > > --Feng > > On Wed, 22 Mar 2006, Shida Schubert wrote: >> >> Hi Rocky; >> >> Why do you want the response identity so bad? >> - As I understand there are two issues, response identity is trying >> to solve. >> Issue 1. Who am I really connected to and is it really who it claims >> it is? >> - Connected Identity solves this problem by allowing the changes >> in From header >> field and re-using the SIP-Identity spec. The Connected-Identity >> spec is nice >> because it reuses what's already there and does not introduce >> any new header for >> indicating identity. And inherit all the nice traits identity >> header provides such as >> integrity etc. >> - Response Identity tries to provide the same thing by introducing >> few new headers >> which clutters the header with more Identity related information. >> Beside there are >> few issues with how one should trust the response-identity(Proxy >> unable to authorize >> the response etc.). >> >> Issue 2. Am I connected to foo as a result of routing decision based >> on my INVITE? >> - Can't really solve the issue with neither of the solution >> described above. >> >> Issue 2 can't be solved by neither of the solution and Issue 1 can >> be solved with >> Connected Identity without adding any extra identity related header. >> So I personally >> don't know why you are so persistent with adopting them both? I think >> Connected-Identity alone satisfies what the WG wants, but I could >> be completely >> wrong. >> >> As for other reason why I don't think they should merge, currently >> they propose two >> completely different solution to address the same problem yet at >> different timing. >> >> And let's not forget, merging the work would create dependency on >> each spec and >> results in creating a delays in overall progress. I have been >> hearing that WG wants to >> resolve Issue 1, in which case delay due to the merge is likely to >> be unacceptable. >> >> Regards >> Shida Schubert >> >> Rocky Wang wrote: >>> I agree with you that there are some requirements to convey the >>> changed >>> identifier. But I think UPDATE and re-INVITE can be used to do so, >>> that is >>> no need to create a 2nd solution. >>> Apart from the mid-dialog requiements, the Connect-URI can be >>> considered >>> as >>> a sub-set of the response identifier. Today we are discussing about >>> conveying the connected URI that return the response, tomorrow, >>> maybe we >>> must re-consider how to convey the identifier which return >>> responses and >>> then we must do the same thing again, including the security and some >>> other >>> problems. >>> What I want to say is that the two drafts can be merged easily from >>> the >>> requirement and expected solution aspects because they are >>> overlapped with >>> each other, and we should do so as my owner opinion. >>> >>> Rocky Wang >>> >>> >>> >>> > -----Original Message----- >>> > From: Elwell, John [mailto:john.elwell@siemens.com] Sent: >>> Wednesday, > March 22, 2006 12:45 PM >>> > To: Rocky Wang; sip@ietf.org >>> > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > >>> draft-elwell-sip-connected-identity-01 >>> > > Rocky, >>> > > The connected-identity draft already gives two examples why a >>> mid-dialog > change would be needed: PSTN gateway and B2BUA. >>> > > We could define a new header field for response identity if >>> this can be > justified, but it would not be secure. I think the >>> consensus yesterday > was to move forward with connected-identity >>> and consider separately > whether response identity is achievable >>> in a way that is secure as well > as adding some value in certain >>> use cases. >>> > > John >>> > > > > > -----Original Message----- >>> > > From: Rocky Wang [mailto:rocky.wang@huawei.com] >>> > > Sent: 22 March 2006 14:44 >>> > > To: Elwell, John; sip@ietf.org >>> > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >>> > > draft-elwell-sip-connected-identity-01 >>> > > > > As my opinion, they two just need take the responser >>> identifier in the > > response messages. We must consider and >>> resolve all the problem > > include the security problems in both >>> cases. >>> > > If you want to indicate a change of party mid-dialog, you > > >>> > can use some > > > mid-dialog method to do it, as I considered, >>> just like UPDATE and > > re-INVITE. >>> > > That's not so difficult in use of exist mechanism. But can > > >>> > you please > > > give me an application case of the usage of >>> mid-dialog entity > > identifier indication. >>> > > > > -----Original Message----- >>> > > From: Elwell, John [mailto:john.elwell@siemens.com] >>> > > Sent: Tuesday, March 21, 2006 11:44 PM >>> > > To: Rocky Wang; sip@ietf.org >>> > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >>> > > draft-elwell-sip-connected-identity-01 >>> > > > > Rocky, >>> > > > > The connected-identity draft is not a subset of the > > > >>> response identity > > > draft. >>> > > The response identity draft cannot be used to indicate a change >>> of > > party mid-dialog. >>> > > > > I don't think we can merge them. There was no consensus on >>> the > > response identity draft. The following views have been >>> expressed: >>> > > - that it does not provide any benefit; >>> > > - that the response identity problem cannot be solved, and that >>> the > > approach taken in the connected-identity draft is the best >>> > > > that can be > > > achieved. >>> > > > > If and when there is consensus on a response identity > > >>> > solution, then > > > we could consider whether it would be >>> appropriate to merge the two, > > but that is not the case at present. >>> > > > > John >>> > > > > > > > -----Original Message----- >>> > > > From: Rocky Wang [mailto:rocky.wang@huawei.com] >>> > > > Sent: 21 March 2006 19:50 >>> > > > To: sip@ietf.org >>> > > > Subject: [Sip] draft-cao-sip-response-identity-00 and >>> > > > draft-elwell-sip-connected-identity-01 >>> > > > > > > > > > Both of draft-cao-sip-response-identity-00 and >>> > > > draft-elwell-sip-connected-identity-01 have been disscussed >>> > > > > > in today's >>> > > > > > SIP session. I found they two can be merged into one. >>> > > > The first one is a common requirement to return back the >>> identity > > > identifier. It can be used in both successful >>> responses, >>> > > > > > but also in >>> > > > > > provisiional, redirect and failure responses, but the 2nd >>> > > > > > one is just >>> > > > > > used for 18X and 2XX response for INVITE (maybe also some >>> > > > > > other type >>> > > > > > requests). >>> > > > As I considered, the 2nd one is just a sub-set case of the >>> > > > > > first one. > > > > > Can merge the 2nd one into the 1st >>> one? Or merge the > > > > requirement of > > > > the 1st into the >>> last. >>> > > > > > > > > > >>>>>> _______________________________________________ >>> > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> > > > This list is for NEW development of the core SIP Protocol Use >>> > > > sip-implementors@cs.columbia.edu for questions on current sip >>> Use > > > sipping@ietf.org for new developments on the application >>> of sip >>> > > > > > > > > >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 11:54:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMT3F-0000RG-Nu; Thu, 23 Mar 2006 11:52:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMT3D-0000Q2-Fn for sip@ietf.org; Thu, 23 Mar 2006 11:52:43 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMT3D-0002xG-1r for sip@ietf.org; Thu, 23 Mar 2006 11:52:43 -0500 Received: from dhcp-wireless-134-205.ietf65.org ([130.129.134.205]) by dns.aliantmedia.net with esmtpa (Exim 4.52) id 1FMT39-0005Mk-Gf; Thu, 23 Mar 2006 10:52:39 -0600 Message-ID: <4422D251.9040405@ntt-at.com> Date: Thu, 23 Mar 2006 08:52:33 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 References: <50B1CBA96870A34799A506B2313F2667087A2D4B@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F2667087A2D4B@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.2 (+) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 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 Feng; Just out of curiosity, what is going to happen when forking takes place and you receive multiple 1xx each with response-identity, and first 200 OK received is from a different UAS to the first 1xx received? If you intend to reflect the response identity in the UI, you might have something like.. 1. "Calling User A" Request sent 2. "Trying to connect to User B" 18x received 3. "Connected to User C" 200 OK received You might want to consider this, as this seems underspecified in the current spec. More comments inline.. Elwell, John wrote: > Feng, > > See below. > > John > > >> -----Original Message----- >> From: Feng Cao [mailto:fcao@cisco.com] >> Sent: 22 March 2006 21:01 >> To: Elwell, John >> Cc: Rocky Wang; sip@ietf.org >> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >> draft-elwell-sip -connected-identity-01 >> >> >> Because connected-id is revealed in the mid-dialog, there are some >> scenarios that are not covered by connected-identity draft. >> >> In general, I agreed with Rocky that the mid-dialog update can be >> easily convered or embeded into the sip identity draft by Jon and >> Cullen. I don't see the need of another new draft for it. >> > [JRE] The identity draft has already been approved. > > >> Some useful scenarios for response identity inside response messages >> had been listed for discussion: >> 1. disclose the response identity for non-dialog session. >> 2. reveal the proxy's identity as the responder for some response >> codes, such as provisiional, redirect and failure responses. >> This will help the callers to make decisions. >> 3. prevent the identity spoofing as early as possible. In some cases, >> it is too late to be notifies of the response identity after the >> dialogs are established. >> > [JRE] Yes, I understand these additional uses that are not covered by the > connected-identity draft. I look forward to reviewing further drafts that > address the problems raised during the meeting. > Some comments on 3 of the scenarios mentioned above: As for 1. I am curious, is it really useful to have identity on non-dialog session? For example if you send a MESSAGE, it's already out there and there is no way to cancel what you sent. Realizing that it was received by a wrong user does not seem too useful. As for 3. You can try to explore the possibility of identity-pre-condition for Connected-Identity where UA will not start sending media until the pre-condition is met. Thanks & Regards Shida Schubert > >> --Feng >> >> >> On Wed, 22 Mar 2006, Elwell, John wrote: >> >>> Rocky, >>> >>> The connected-identity draft already gives two examples why >>> >> a mid-dialog >> >>> change would be needed: PSTN gateway and B2BUA. >>> >>> We could define a new header field for response identity if >>> >> this can be >> >>> justified, but it would not be secure. I think the >>> >> consensus yesterday was >> >>> to move forward with connected-identity and consider >>> >> separately whether >> >>> response identity is achievable in a way that is secure as >>> >> well as adding >> >>> some value in certain use cases. >>> >>> John >>> >>> >>> >>>> -----Original Message----- >>>> From: Rocky Wang [mailto:rocky.wang@huawei.com] >>>> Sent: 22 March 2006 14:44 >>>> To: Elwell, John; sip@ietf.org >>>> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >>>> draft-elwell-sip-connected-identity-01 >>>> >>>> As my opinion, they two just need take the responser >>>> identifier in the >>>> response messages. We must consider and resolve all the >>>> problem include the >>>> security problems in both cases. >>>> If you want to indicate a change of party mid-dialog, you >>>> >> can use some >> >>>> mid-dialog method to do it, as I considered, just like UPDATE >>>> and re-INVITE. >>>> That's not so difficult in use of exist mechanism. But can >>>> you please give >>>> me an application case of the usage of mid-dialog entity identifier >>>> indication. >>>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>> Sent: Tuesday, March 21, 2006 11:44 PM >>>> To: Rocky Wang; sip@ietf.org >>>> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >>>> draft-elwell-sip-connected-identity-01 >>>> >>>> Rocky, >>>> >>>> The connected-identity draft is not a subset of the response >>>> identity draft. >>>> The response identity draft cannot be used to indicate a >>>> change of party >>>> mid-dialog. >>>> >>>> I don't think we can merge them. There was no consensus on >>>> the response >>>> identity draft. The following views have been expressed: >>>> - that it does not provide any benefit; >>>> - that the response identity problem cannot be solved, and >>>> that the approach >>>> taken in the connected-identity draft is the best that can be >>>> achieved. >>>> >>>> If and when there is consensus on a response identity >>>> solution, then we >>>> could consider whether it would be appropriate to merge the >>>> two, but that is >>>> not the case at present. >>>> >>>> John >>>> >>>> >>>>> -----Original Message----- >>>>> From: Rocky Wang [mailto:rocky.wang@huawei.com] >>>>> Sent: 21 March 2006 19:50 >>>>> To: sip@ietf.org >>>>> Subject: [Sip] draft-cao-sip-response-identity-00 and >>>>> draft-elwell-sip-connected-identity-01 >>>>> >>>>> >>>>> Both of draft-cao-sip-response-identity-00 and >>>>> draft-elwell-sip-connected-identity-01 have been disscussed >>>>> >>>> in today's >>>> >>>>> SIP session. I found they two can be merged into one. >>>>> The first one is a common requirement to return back the identity >>>>> identifier. It can be used in both successful responses, >>>>> >>>> but also in >>>> >>>>> provisiional, redirect and failure responses, but the 2nd >>>>> >>>> one is just >>>> >>>>> used for 18X and 2XX response for INVITE (maybe also some >>>>> >>>> other type >>>> >>>>> requests). >>>>> As I considered, the 2nd one is just a sub-set case of the >>>>> >>>> first one. >>>> >>>>> Can merge the 2nd one into the 1st one? Or merge the >>>>> >> requirement of >> >>>>> the 1st into the last. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>> sipping@ietf.org for new developments on the application of sip >>>>> >>>>> >>>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 12:37:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTiN-0003eI-HK; Thu, 23 Mar 2006 12:35:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTiM-0003eD-Hp for sip@ietf.org; Thu, 23 Mar 2006 12:35:14 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMTiL-0005FI-8a for sip@ietf.org; Thu, 23 Mar 2006 12:35:14 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id BC9C86C017 for ; Thu, 23 Mar 2006 12:35:10 -0500 (EST) Subject: RE: [Sip] comments on location conveyance draft From: "Dale R. Worley" To: Sip In-Reply-To: <422D410BD61FC04185076AD99AA7207A01771F16@inilmx01.lgmt.trdo> References: <422D410BD61FC04185076AD99AA7207A01771F16@inilmx01.lgmt.trdo> Content-Type: text/plain Date: Thu, 23 Mar 2006 12:35:10 -0500 Message-Id: <1143135310.12925.51.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Wed, 2006-03-22 at 19:30 -0600, McCalmont, Patti wrote: > A UAC MUST be prevented from disabling conveyance of location for > an emergency call if local jurisdiction (laws of that particular > country) requires it. I think a requirement like this should be put into the draft. Not because I think that necessarily every UAC should follow this rule -- there are a host of complex issues here -- but because stating this as a requirement will tend to cause UACs to be non-compliant only when someone gave the issue serious consideration, instead of being non- compliant because the implementer overlooked the issue. (I would rephrase the requirement something like this: "A UAC MUST convey its location for an emergency call if it is required by the local jurisdiction.") 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 Mar 23 12:46:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTrp-00046u-Fx; Thu, 23 Mar 2006 12:45:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTrn-00043o-Ef for sip@ietf.org; Thu, 23 Mar 2006 12:44:59 -0500 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMTrm-0005TY-8z for sip@ietf.org; Thu, 23 Mar 2006 12:44:59 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.13.4) with ESMTP id k2NHw9Af025507; Thu, 23 Mar 2006 12:58:09 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 12:44:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Mar 2006 12:44:56 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on draft-gurbani-sip-tls-use-00 Thread-Index: AcZOoX/nrNfIu1PkSseRjcpmp0CJMg== From: "Walker, Charles" To: X-OriginalArrivalTime: 23 Mar 2006 17:44:57.0766 (UTC) FILETIME=[80685460:01C64EA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org Subject: [Sip] Comment on draft-gurbani-sip-tls-use-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 worked on an implementation of SIP over TLS, so I'm glad that you are working on this draft. I could have used something like this back when I was implementing SIP over TLS. When I read section 5.2, I really did not like P2 doing a reverse DNS lookup to get P1's host name. I thought it unnecessary since P1 is proving that it has the private key when it does the CERTIFICATE VERIFY. However, on reflection, I recant my objection. Just because somebody has a certificate and the associated private key, does not mean that the certificate/key pair is for the meant for the host that it is actually installed on. P2 does need to somehow match the host name of P1 against the host name in the certificate. The reverse DNS lookup is not perfect, but it's better than nothing. Regards, Charles Walker VeriSign, 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 Thu Mar 23 14:35:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVZG-0006ap-MK; Thu, 23 Mar 2006 14:33:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVZF-0006Ym-1u for sip@ietf.org; Thu, 23 Mar 2006 14:33:57 -0500 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 1FMVZE-0001OE-H0 for sip@ietf.org; Thu, 23 Mar 2006 14:33:57 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 23 Mar 2006 11:33:56 -0800 Received: from billybong.cisco.com (billybong.cisco.com [171.71.163.234]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2NJXtGw000926; Thu, 23 Mar 2006 11:33:56 -0800 (PST) Date: Thu, 23 Mar 2006 11:33:55 -0800 (PST) From: Feng Cao To: Shida Schubert Subject: Re: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 In-Reply-To: <4422D251.9040405@ntt-at.com> Message-ID: References: <50B1CBA96870A34799A506B2313F2667087A2D4B@ntht201e.siemenscomms.co.uk> <4422D251.9040405@ntt-at.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: sip@ietf.org, "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 The next version will try to cover more cases you raised. Thanks, --Feng On Thu, 23 Mar 2006, Shida Schubert wrote: > > Hi Feng; > > Just out of curiosity, what is going to happen when forking > takes place and you receive multiple 1xx each with > response-identity, and first 200 OK received is from a different > UAS to the first 1xx received? > > If you intend to reflect the response identity in the UI, you > might have something like.. > > 1. "Calling User A" Request sent > 2. "Trying to connect to User B" 18x received > 3. "Connected to User C" 200 OK received > > You might want to consider this, as this seems underspecified > in the current spec. > > More comments inline.. > > Elwell, John wrote: >> Feng, >> >> See below. >> >> John >> >> >>> -----Original Message----- >>> From: Feng Cao [mailto:fcao@cisco.com] >>> Sent: 22 March 2006 21:01 >>> To: Elwell, John >>> Cc: Rocky Wang; sip@ietf.org >>> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >>> draft-elwell-sip -connected-identity-01 >>> >>> >>> Because connected-id is revealed in the mid-dialog, there are some >>> scenarios that are not covered by connected-identity draft. >>> >>> In general, I agreed with Rocky that the mid-dialog update can be >>> easily convered or embeded into the sip identity draft by Jon and >>> Cullen. I don't see the need of another new draft for it. >>> >> [JRE] The identity draft has already been approved. >> >> >>> Some useful scenarios for response identity inside response messages >>> had been listed for discussion: >>> 1. disclose the response identity for non-dialog session. >>> 2. reveal the proxy's identity as the responder for some response >>> codes, such as provisiional, redirect and failure responses. >>> This will help the callers to make decisions. >>> 3. prevent the identity spoofing as early as possible. In some cases, >>> it is too late to be notifies of the response identity after the >>> dialogs are established. >>> >> [JRE] Yes, I understand these additional uses that are not covered by the >> connected-identity draft. I look forward to reviewing further drafts that >> address the problems raised during the meeting. >> > > Some comments on 3 of the scenarios mentioned above: > > As for 1. I am curious, is it really useful to have identity on > non-dialog session? > For example if you send a MESSAGE, it's already out there and there is > no way > to cancel what you sent. Realizing that it was received by a wrong user > does not > seem too useful. > > As for 3. You can try to explore the possibility of > identity-pre-condition for Connected-Identity > where UA will not start sending media until the pre-condition is met. > > Thanks & Regards > Shida Schubert >> >>> --Feng >>> >>> >>> On Wed, 22 Mar 2006, Elwell, John wrote: >>> >>>> Rocky, >>>> >>>> The connected-identity draft already gives two examples why >>>> >>> a mid-dialog >>> >>>> change would be needed: PSTN gateway and B2BUA. >>>> >>>> We could define a new header field for response identity if >>>> >>> this can be >>> >>>> justified, but it would not be secure. I think the >>>> >>> consensus yesterday was >>> >>>> to move forward with connected-identity and consider >>>> >>> separately whether >>> >>>> response identity is achievable in a way that is secure as >>>> >>> well as adding >>> >>>> some value in certain use cases. >>>> >>>> John >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Rocky Wang [mailto:rocky.wang@huawei.com] >>>>> Sent: 22 March 2006 14:44 >>>>> To: Elwell, John; sip@ietf.org >>>>> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >>>>> draft-elwell-sip-connected-identity-01 >>>>> >>>>> As my opinion, they two just need take the responser >>>>> identifier in the >>>>> response messages. We must consider and resolve all the >>>>> problem include the >>>>> security problems in both cases. >>>>> If you want to indicate a change of party mid-dialog, you >>>>> >>> can use some >>> >>>>> mid-dialog method to do it, as I considered, just like UPDATE >>>>> and re-INVITE. >>>>> That's not so difficult in use of exist mechanism. But can >>>>> you please give >>>>> me an application case of the usage of mid-dialog entity identifier >>>>> indication. >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>>> Sent: Tuesday, March 21, 2006 11:44 PM >>>>> To: Rocky Wang; sip@ietf.org >>>>> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and >>>>> draft-elwell-sip-connected-identity-01 >>>>> >>>>> Rocky, >>>>> >>>>> The connected-identity draft is not a subset of the response >>>>> identity draft. >>>>> The response identity draft cannot be used to indicate a >>>>> change of party >>>>> mid-dialog. >>>>> >>>>> I don't think we can merge them. There was no consensus on >>>>> the response >>>>> identity draft. The following views have been expressed: >>>>> - that it does not provide any benefit; >>>>> - that the response identity problem cannot be solved, and >>>>> that the approach >>>>> taken in the connected-identity draft is the best that can be >>>>> achieved. >>>>> >>>>> If and when there is consensus on a response identity >>>>> solution, then we >>>>> could consider whether it would be appropriate to merge the >>>>> two, but that is >>>>> not the case at present. >>>>> >>>>> John >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Rocky Wang [mailto:rocky.wang@huawei.com] >>>>>> Sent: 21 March 2006 19:50 >>>>>> To: sip@ietf.org >>>>>> Subject: [Sip] draft-cao-sip-response-identity-00 and >>>>>> draft-elwell-sip-connected-identity-01 >>>>>> >>>>>> >>>>>> Both of draft-cao-sip-response-identity-00 and >>>>>> draft-elwell-sip-connected-identity-01 have been disscussed >>>>>> >>>>> in today's >>>>> >>>>>> SIP session. I found they two can be merged into one. >>>>>> The first one is a common requirement to return back the identity >>>>>> identifier. It can be used in both successful responses, >>>>>> >>>>> but also in >>>>> >>>>>> provisiional, redirect and failure responses, but the 2nd >>>>>> >>>>> one is just >>>>> >>>>>> used for 18X and 2XX response for INVITE (maybe also some >>>>>> >>>>> other type >>>>> >>>>>> requests). >>>>>> As I considered, the 2nd one is just a sub-set case of the >>>>>> >>>>> first one. >>>>> >>>>>> Can merge the 2nd one into the 1st one? Or merge the >>>>>> >>> requirement of >>> >>>>>> the 1st into the last. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>>> sipping@ietf.org for new developments on the application of sip >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> >> >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 15:50:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWjb-00019g-Pj; Thu, 23 Mar 2006 15:48:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWjZ-00017t-AB for sip@ietf.org; Thu, 23 Mar 2006 15:48:41 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMWjX-0004uk-Tz for sip@ietf.org; Thu, 23 Mar 2006 15:48:41 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 23 Mar 2006 12:48:39 -0800 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 k2NKmcw1009983; Thu, 23 Mar 2006 12:48:38 -0800 (PST) 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.211); Thu, 23 Mar 2006 12:48:38 -0800 Received: from [10.89.16.74] ([10.89.16.74]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Mar 2006 12:48:37 -0800 Message-ID: <442309A4.7060004@cisco.com> Date: Thu, 23 Mar 2006 15:48:36 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Enrico Marocco Subject: Re: [Sip] The Problem with PRACK References: <072C5B76F7CEAB488172C6F64B30B5E3013D7D20@xmb-rtp-20b.amer.cisco.com> <441ECB93.1040008@estacado.net> <44203439.60107@telecomitalia.it> In-Reply-To: <44203439.60107@telecomitalia.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2006 20:48:37.0757 (UTC) FILETIME=[28D582D0:01C64EBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Adam Roach , sip@ietf.org, jh@tutpro.com, Alberto Cuda , christer.holmberg@ericsson.com, drage@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 Enrico, I remember reading your draft when it first came out, and I thought I commented on it. But I cannot find any record of actually sending comments. :-( I'm not taking time to read it carefully again now. But based on a glance, it appears to be consistent with my reaction to the 329 state FSM: this thing needs to be factored. The obvious factoring is into an offer/answer fsm, an invite-dialog-usage fsm, and a transaction fsm. There is also need for a dialog state machine, but it isn't an fsm because it requires counting, and it is pretty trivial. I would also observe that the 329 state fsm is incomplete because it doesn't support early-session. (At least I don't think so.) It is in theory possible to have an offer/answer fsm for session and an offer/answer fsm for early-session in progress, and in different states, attached to the same invite-dialog-usage fsm. Paul Enrico Marocco wrote: > > A couple of mounts age we have submitted an informational draft > (draft-cuda-sipping-ua-fsm-00) describing an alternative and hopefully > more intuitive formal model for representing the full negotiation. The > effort of that draft was on separating and showing relations between the > three state machine involved in the process (session, media negotiation > and signalling). > > Maybe it could be somewhat userful in this analysis. > > Enrico > > Adam Roach wrote: > > Michael Hammer (mhammer) wrote: > > > >> Anyway, I haven't seen the 50+ state diagram from Vancouver either, but > >> it would be good to have that distributed on the mail list. I must have > >> missed that one if it was. > >> > >> > > Because the graphic doesn't work well on a mailing list, I've put it > > here in text format. If you want the visual impact of the graph that > > Rohan put up at IETF64, grab the PDF file at > > > http://scm.sipfoundry.org/viewsvn/*checkout*/resiprocate/main/resip/dum/doc/dum-fsms1.pdf > > > > > > > This comes from the Dialog Usage Manager in the resiprocate stack; the > > transition is denoted as "oldstate->newstate"; the trigger and > > subsequent actions are indicated following that line. > > [sorry, dropped for honouring 40K size limit] > -------------------------------------------------------------------- > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by > replying to webmaster@telecomitalia.it . > Thank you > www.telecomitalia.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 Thu Mar 23 17:03:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMXs2-0005iy-44; Thu, 23 Mar 2006 17:01:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMXs0-0005ih-Te; Thu, 23 Mar 2006 17:01:28 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMX1C-0006fS-KZ; Thu, 23 Mar 2006 16:06:54 -0500 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FMWtY-0006BH-89; Thu, 23 Mar 2006 15:59:01 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2NKwxBX027289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Mar 2006 20:59:00 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FMWtX-0003jk-Sg; Thu, 23 Mar 2006 15:58:59 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 23 Mar 2006 15:58:59 -0500 X-Spam-Score: -5.8 (-----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org Subject: [Sip] Last Call: 'Management Information Base for the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Management Information Base for the Session Initiation Protocol (SIP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-10.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 Thu Mar 23 18:35:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMZIr-0004Tz-Tt; Thu, 23 Mar 2006 18:33:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAfX-0007uO-40; Wed, 22 Mar 2006 16:15:03 -0500 Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAfV-0003Bc-Sq; Wed, 22 Mar 2006 16:15:03 -0500 Received: from optonline.net (hamstr6.srv.hcvlny.cv.net [167.206.5.18]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0IWJ002U3SCFMDD0@mta2.srv.hcvlny.cv.net>; Wed, 22 Mar 2006 16:14:40 -0500 (EST) Received: from [10.240.3.37] (Forwarded-For: [130.129.133.29]) by mstr6.srv.hcvlny.cv.net (mshttpd); Wed, 22 Mar 2006 16:14:39 -0500 Date: Wed, 22 Mar 2006 16:14:39 -0500 From: pthermos@optonline.net Subject: Re: [Sip] VoIP security mailing list In-reply-to: <01b901c64def$b2756b80$9353150a@amer.cisco.com> To: Dan Wing Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-4.03 (built Sep 22 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <01b901c64def$b2756b80$9353150a@amer.cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Thu, 23 Mar 2006 18:33:16 -0500 Cc: 'sip ietf' , sipping@ietf.org, mmusic@ietf.org, avt@ietf.org, msec@securemulticast.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 some related information (papers) and a mailing list at vopsecurity.org ----- Original Message ----- From: Dan Wing Date: Wednesday, March 22, 2006 3:32 pm Subject: [Sip] VoIP security mailing list > During my RAI presentation yesterday a few people said they were > unfamiliarwith the VoIP security mailing list that I referred to. > The mailing list is > run by the VoIP Security Alliance . The page > has links to subscribe and view archives. > > -Dan Wing > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 23 19:10:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMZrK-0007Tw-TU; Thu, 23 Mar 2006 19:08:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMZgs-0002PA-BR for sip@ietf.org; Thu, 23 Mar 2006 18:58:06 -0500 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMZeB-0006VP-Lq for sip@ietf.org; Thu, 23 Mar 2006 18:55:22 -0500 thread-index: AcZO1TPlszuI8nZHT8ijT191xoQZkQ== Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Mar 2006 00:55:03 +0100 Received: from PTPXCH029BA020.idc.cww.telecomitalia.it ([156.54.240.46]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Mar 2006 00:55:18 +0100 Received: from [163.162.113.134] ([163.162.113.134]) by PTPXCH029BA020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Mar 2006 00:55:17 +0100 Message-ID: <442335C0.9030309@telecomitalia.it> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-Class: urn:content-classes:message Importance: normal Priority: normal Date: Thu, 23 Mar 2006 17:56:48 -0600 From: "Enrico Marocco" User-Agent: Mail/News 1.5 (X11/20060228) MIME-Version: 1.0 To: "Paul Kyzivat" Subject: Re: [Sip] The Problem with PRACK References: <072C5B76F7CEAB488172C6F64B30B5E3013D7D20@xmb-rtp-20b.amer.cisco.com> <441ECB93.1040008@estacado.net> <44203439.60107@telecomitalia.it> <442309A4.7060004@cisco.com> In-Reply-To: <442309A4.7060004@cisco.com> X-OriginalArrivalTime: 23 Mar 2006 23:55:17.0836 (UTC) FILETIME=[3C99F0C0:01C64ED5] X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Adam Roach , sip@ietf.org, jh@tutpro.com, Alberto Cuda , christer.holmberg@ericsson.com, drage@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: , Content-Type: multipart/mixed; boundary="===============0975378696==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0975378696== Content-Type: multipart/alternative; boundary="----=_NextPart_000_13B060_01C64EDD.95AA4220" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_13B060_01C64EDD.95AA4220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul Kyzivat wrote: > I remember reading your draft when it first came out, and I thought I > commented on it. But I cannot find any record of actually sending > comments. :-( Actually we haven't received any. > I'm not taking time to read it carefully again now. But based on a > glance, it appears to be consistent with my reaction to the 329 state > FSM: this thing needs to be factored. The obvious factoring is into an > offer/answer fsm, an invite-dialog-usage fsm, and a transaction fsm. That's basically our approach. We've come to it in the effort of reducing the mess introduced in our stack by adding support for the insane 3gpp handshake; that's why it is much (maybe too) "implementation oriented". Enrico -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_13B060_01C64EDD.95AA4220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Paul Kyzivat = wrote:
> I remember reading your draft when it first came out, and I = thought I
> commented on it. But I cannot find any record of actually = sending
> comments. :-(

Actually we haven't received = any.

> I'm not taking time to read it carefully again now. But = based on a
> glance, it appears to be consistent with my reaction to = the 329 state
> FSM: this thing needs to be factored. The obvious = factoring is into an
> offer/answer fsm, an invite-dialog-usage fsm, = and a transaction fsm.

That's basically our approach. We've come = to it in the effort of
reducing the mess introduced in our stack by = adding support for the
insane 3gpp handshake; that's why it is much = (maybe too) "implementation
oriented".

Enrico
--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_13B060_01C64EDD.95AA4220-- --===============0975378696== 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 --===============0975378696==-- From sip-bounces@ietf.org Fri Mar 24 00:39:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMezT-0000Jw-5Q; Fri, 24 Mar 2006 00:37:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMezR-0000C1-IK for sip@ietf.org; Fri, 24 Mar 2006 00:37:37 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMezQ-0005n5-3q for sip@ietf.org; Fri, 24 Mar 2006 00:37:37 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FMezN-0000rM-PM for sip@ietf.org; Fri, 24 Mar 2006 07:37:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17443.34205.560550.825661@harjus.tutpro.com> Date: Fri, 24 Mar 2006 07:37:33 +0200 To: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org outbound version 03 still doesn't address auto-discovery of the outbound-proxy-set. as i have said in before, the specification is in practise useless and should not be published as an RFC unless there is a standard (preferably DNS based way) to do so. -- 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 Fri Mar 24 02:14:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMgTd-0005Sm-E5; Fri, 24 Mar 2006 02:12:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMgTb-0005Sh-TQ for sip@ietf.org; Fri, 24 Mar 2006 02:12:51 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMgTW-00013O-Ds for sip@ietf.org; Fri, 24 Mar 2006 02:12:51 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 123E84F0002; Fri, 24 Mar 2006 08:12:12 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 08:12:11 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 08:12:11 +0100 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-outbound-03.txt Date: Fri, 24 Mar 2006 08:12:10 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1BAE@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZPBUyeKJqY6mzJT0CCpiQAmLxOiwADJCrA From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , X-OriginalArrivalTime: 24 Mar 2006 07:12:11.0490 (UTC) FILETIME=[45281C20:01C64F12] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Juha, Maybe I am missing the point, but please clarify the following thing. You say that you don't want to mandate the outbound proxy to be configured. You say that you want to use DNS. Now, if you want to use DNS, what are you going to do your DNS lookup on? If you do the DNS lookup based on the Request-URI, what is there to standardize? Isn't that normal SIP routing behavior? If you do the DNS lookup on something else, don't you need to configure that? Regards, Christer =20 -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 24. maaliskuuta 2006 7:38 To: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt=20 outbound version 03 still doesn't address auto-discovery of the outbound-proxy-set. as i have said in before, the specification is in practise useless and should not be published as an RFC unless there is a standard (preferably DNS based way) to do so. -- 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 Fri Mar 24 02:41:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMgtr-0006f2-Tn; Fri, 24 Mar 2006 02:39:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMgtq-0006cw-9x for sip@ietf.org; Fri, 24 Mar 2006 02:39:58 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMggE-0001VD-AR for sip@ietf.org; Fri, 24 Mar 2006 02:25:55 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FMggD-0001It-4i; Fri, 24 Mar 2006 09:25:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17443.40705.62162.562433@harjus.tutpro.com> Date: Fri, 24 Mar 2006 09:25:53 +0200 To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1BAE@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1BAE@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Christer Holmberg (JO/LMF) writes: > Now, if you want to use DNS, what are you going to do your DNS lookup > on? you didn't obviously read my earlier message on this. in that i said, that it must be enough to configure three thing in the UA: username, password and AoR. the lookup of outbound-proxy-set is done based on host part of AoR. -- 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 Fri Mar 24 02:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMguV-0006p8-Re; Fri, 24 Mar 2006 02:40:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMgtd-0006UA-W9 for sip@ietf.org; Fri, 24 Mar 2006 02:39:45 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMgpV-0001ks-2m for sip@ietf.org; Fri, 24 Mar 2006 02:35:31 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 84B0C4F0006; Fri, 24 Mar 2006 08:35:28 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 08:35:28 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 08:35:28 +0100 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-outbound-03.txt Date: Fri, 24 Mar 2006 08:35:27 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1BB0@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZPFDNj0rAAuxRTRKymHg+Vp/8cBQAAKqWQ From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 24 Mar 2006 07:35:28.0189 (UTC) FILETIME=[85A776D0:01C64F15] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 DID read your previous mail. But, are you going to do the DNS lookup based on the AoR value of the terminal (the value you normally put in the From header)? What if there are different outbound proxies depending on the destination? What is the outbound proxy belongs to another operator/domain (i.e. another "host part")? And, would you use some kind of dedicated private DNS for this? Regards, Christer -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 24. maaliskuuta 2006 9:26 To: Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt=20 Christer Holmberg (JO/LMF) writes: > Now, if you want to use DNS, what are you going to do your DNS lookup > on? you didn't obviously read my earlier message on this. in that i said, that it must be enough to configure three thing in the UA: username, password and AoR. the lookup of outbound-proxy-set is done based on host part of AoR. -- 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 Fri Mar 24 03:05:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhGt-0004dn-Pg; Fri, 24 Mar 2006 03:03:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhGs-0004ck-Bl for sip@ietf.org; Fri, 24 Mar 2006 03:03:46 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMhGo-00030A-PZ for sip@ietf.org; Fri, 24 Mar 2006 03:03:46 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FMhGn-0001K8-VD; Fri, 24 Mar 2006 10:03:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17443.42973.890178.510188@harjus.tutpro.com> Date: Fri, 24 Mar 2006 10:03:41 +0200 To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1BB0@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1BB0@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Christer Holmberg (JO/LMF) writes: > But, are you going to do the DNS lookup based on the AoR value of the > terminal (the value you normally put in the From header)? What if there > are different outbound proxies depending on the destination? i don't understand how register requests would have many destinations. what comes to other (initial) requests, the default would be that the UA sends them to the proxies in THE outbound-proxy-set (if specified). if your world is more complex, you can always provide any kind of other (manual) configuration possibilities. so what i'm trying to say that ietf must define DNS based auto-configuration of outbound-proxy-set for the COMMON case, where there is a single outbound-proxy-set that is used for all destinations. -- 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 Fri Mar 24 03:36:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhkY-0001FI-T1; Fri, 24 Mar 2006 03:34:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhkW-0001FD-Or for sip@ietf.org; Fri, 24 Mar 2006 03:34:24 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMhkU-0003kC-50 for sip@ietf.org; Fri, 24 Mar 2006 03:34:24 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 92C0CC91; Fri, 24 Mar 2006 09:34:21 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 09:34:21 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 09:34:20 +0100 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-outbound-03.txt Date: Fri, 24 Mar 2006 09:34:20 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1BB4@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZPGXl6F8dB6sapSDGwDKV5B1gFhAAAgSMg From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 24 Mar 2006 08:34:20.0948 (UTC) FILETIME=[BF57B540:01C64F1D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Juha, You are probably always going to use the same AoR for your registrations request, but that still doesn't mean you will use the same outbound proxies.=20 Maybe when your phone is "statically located" you are always going to use the same outbound proxy. But, what about mobility? Is that out of the scope of this? Regards, Christer -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 24. maaliskuuta 2006 10:04 To: Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt=20 Christer Holmberg (JO/LMF) writes: > But, are you going to do the DNS lookup based on the AoR value of the > terminal (the value you normally put in the From header)? What if there > are different outbound proxies depending on the destination?=20 i don't understand how register requests would have many destinations. what comes to other (initial) requests, the default would be that the UA sends them to the proxies in THE outbound-proxy-set (if specified). if your world is more complex, you can always provide any kind of other (manual) configuration possibilities. so what i'm trying to say that ietf must define DNS based auto-configuration of outbound-proxy-set for the COMMON case, where there is a single outbound-proxy-set that is used for all destinations. -- 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 Fri Mar 24 03:47:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhv4-0004qL-Hj; Fri, 24 Mar 2006 03:45:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhv3-0004qG-Fy for sip@ietf.org; Fri, 24 Mar 2006 03:45:17 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMhv2-00043b-4k for sip@ietf.org; Fri, 24 Mar 2006 03:45:17 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FMhv0-0001M0-La; Fri, 24 Mar 2006 10:45:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17443.45466.140124.375690@harjus.tutpro.com> Date: Fri, 24 Mar 2006 10:45:14 +0200 To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1BB4@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1BB4@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Christer Holmberg (JO/LMF) writes: > Maybe when your phone is "statically located" you are always going to > use the same outbound proxy. But, what about mobility? Is that out of > the scope of this? yes, it is out of the scope of the COMMON case. the common case is that the sip ua is free, no matter where it is currently located, to use the same set of outbound proxies, i.e., the ones of own domain. if sip ua is behind a firewall that blocks outbound sip traffic or in some kind of 3gpp walled garden, where you want to milk the cow many times, then you can provide any other configuration methods. -- 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 Fri Mar 24 04:01:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMi8k-0000B1-6A; Fri, 24 Mar 2006 03:59:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMi8i-00008v-Dx for sip@ietf.org; Fri, 24 Mar 2006 03:59:24 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMi8g-0004pr-TX for sip@ietf.org; Fri, 24 Mar 2006 03:59:24 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 65D744F0005; Fri, 24 Mar 2006 09:59:22 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 09:59:22 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 09:59:21 +0100 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-outbound-03.txt Date: Fri, 24 Mar 2006 09:59:21 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1BB5@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZPH02Wavt92T+1TFSTYF7WtJPh6AAAa9Vw From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 24 Mar 2006 08:59:21.0762 (UTC) FILETIME=[3DE5C020:01C64F21] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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, Assume that you use your SIP phone at home, which belongs to operator A. Then you take your phone somewhere else, and connects it to a network that belongs to operator B. In both cases the AoR of the registrar is going to be the same, but you may have different outbound proxies. Now, if that is out of the scope it's fine, but I don't really see any walled garden about it... Regards, Christer=20 -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 24. maaliskuuta 2006 10:45 To: Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt=20 Christer Holmberg (JO/LMF) writes: > Maybe when your phone is "statically located" you are always going to > use the same outbound proxy. But, what about mobility? Is that out of > the scope of this? yes, it is out of the scope of the COMMON case. the common case is that the sip ua is free, no matter where it is currently located, to use the same set of outbound proxies, i.e., the ones of own domain. if sip ua is behind a firewall that blocks outbound sip traffic or in some kind of 3gpp walled garden, where you want to milk the cow many times, then you can provide any other configuration methods. -- 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 Fri Mar 24 04:30:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMial-0005Ov-BA; Fri, 24 Mar 2006 04:28:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMiaj-0005Oq-Oj for sip@ietf.org; Fri, 24 Mar 2006 04:28:21 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMiai-0006pG-E7 for sip@ietf.org; Fri, 24 Mar 2006 04:28:21 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FMiah-0001NZ-Go; Fri, 24 Mar 2006 11:28:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17443.48051.461491.505003@harjus.tutpro.com> Date: Fri, 24 Mar 2006 11:28:19 +0200 To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1BB5@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1BB5@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Christer Holmberg (JO/LMF) writes: > Assume that you use your SIP phone at home, which belongs to operator A. > Then you take your phone somewhere else, and connects it to a network > that belongs to operator B. In both cases the AoR of the registrar is > going to be the same, but you may have different outbound proxies. i may be old fashioned, but it used to be the case that if my pbone is connected to internet via ISP A network and i move it to ISP B network, i'm in both cases able to reach the internet connected proxy (perhaps in ISP C network) of my own domain. --- 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 Fri Mar 24 04:51:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMivX-0000Rg-1w; Fri, 24 Mar 2006 04:49:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMivW-0000Rb-1K for sip@ietf.org; Fri, 24 Mar 2006 04:49:50 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMivU-0007DX-EV for sip@ietf.org; Fri, 24 Mar 2006 04:49:50 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A7C7E6D2; Fri, 24 Mar 2006 10:49:47 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 10:49:47 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 10:49:47 +0100 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-outbound-03.txt Date: Fri, 24 Mar 2006 10:49:45 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1BB7@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZPJUscJcQQDXVzRDGQQAslTPKnhgAAq4JQ From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 24 Mar 2006 09:49:47.0072 (UTC) FILETIME=[491F6C00:01C64F28] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 >Assume that you use your SIP phone at home, which belongs to operator A. >Then you take your phone somewhere else, and connects it to a network =20 >that belongs to operator B. In both cases the AoR of the registrar is =20 >going to be the same, but you may have different outbound proxies. >i may be old fashioned, but it used to be the case that if my pbone is connected to internet via ISP A network and i move=20 >it to ISP B network, i'm in both cases able to reach the internet connected proxy (perhaps in ISP C network) of my own=20 >domain.=20 What if both ISP A and ISP B have an outbound proxy, and you do your DNS lookup based on the AoR of the registrar in ISP C. Again, will you use private ISP A DNS servers (or private ISP B DNS servers) in order to find the appropirate outbound proxy? 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 Mar 24 06:34:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMkWe-0008Pk-3N; Fri, 24 Mar 2006 06:32:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMkWd-0008Pf-9z for sip@ietf.org; Fri, 24 Mar 2006 06:32:15 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMkWb-0002db-Vo for sip@ietf.org; Fri, 24 Mar 2006 06:32:15 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FMkWa-0001PQ-MX; Fri, 24 Mar 2006 13:32:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17443.55484.641744.218873@harjus.tutpro.com> Date: Fri, 24 Mar 2006 13:32:12 +0200 To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1BB7@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1BB7@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Christer Holmberg (JO/LMF) writes: > What if both ISP A and ISP B have an outbound proxy, and you do your DNS > lookup based on the AoR of the registrar in ISP C. Again, will you use > private ISP A DNS servers (or private ISP B DNS servers) in order to > find the appropirate outbound proxy? huh, i didn't know that ISP DNS servers are nowadays private. my AoR is sip:jh@tutpro.com. are you saying that if i make a dsn query host -t SRV _sip._udp.tutpro.com _sip._udp.tutpro.com SRV 0 0 5060 sip.tutpro.com. in ISP A network, i may get some other result than the ne above? if so, there is nothing left of open internet. -- 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 Fri Mar 24 06:57:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMktM-00039k-0Z; Fri, 24 Mar 2006 06:55:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMkt3-00028c-Qs for sip@ietf.org; Fri, 24 Mar 2006 06:55:25 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMkj2-0002oZ-M2 for sip@ietf.org; Fri, 24 Mar 2006 06:45:06 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 020504F0002; Fri, 24 Mar 2006 12:45:04 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 12:45:03 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 12:45:03 +0100 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-outbound-03.txt Date: Fri, 24 Mar 2006 12:45:02 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1BBE@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZPNqPvU5Gsv8pyTQW948nkE1MTiQAAHL3g From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 24 Mar 2006 11:45:03.0274 (UTC) FILETIME=[638018A0:01C64F38] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Juha,=20 >>What if both ISP A and ISP B have an outbound proxy, and you do your DNS =20 >>lookup based on the AoR of the registrar in ISP C. Again, will you use >>private ISP A DNS servers (or private ISP B DNS servers) in order to =20 >>find the appropirate outbound proxy? >> >huh, i didn't know that ISP DNS servers are nowadays private. my AoR is sip:jh@tutpro.com. are you saying that if i make a dsn query=20 > >host -t SRV _sip._udp.tutpro.com >_sip._udp.tutpro.com SRV 0 0 5060 sip.tutpro.com. > >in ISP A network, i may get some other result than the ne above? if so, there is nothing left of open internet. What I am saying is: if your outbound proxy is located in the ISP A network (evil.walled.garden.com), and you do the DNS lookup based on ISP C (free.and.open.tutpro.com), where your registrar is located, how will the DNS return the address of a outbound proxy within the evil.walled.garden.com domain? I don't think we can assume that the outbound proxy and the registrar are the same thing, or that they are located in the same domain/AoR. And, what I mean by "private DNS server" was a server which is only valid for routing within ISP A. For example, a DNS lookup on an ISP C AoR would return the address of a node (the outbound proxy) in ISP A. No, I didn't say that is what you should do - I was simply asking if that is what you meant. But, obviously not :) 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 Mar 24 07:54:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMlmI-00028g-To; Fri, 24 Mar 2006 07:52:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMlmH-00027e-PE for sip@ietf.org; Fri, 24 Mar 2006 07:52:29 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMlmG-00059s-1K for sip@ietf.org; Fri, 24 Mar 2006 07:52:29 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E372B5C4; Fri, 24 Mar 2006 13:52:24 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 13:52:24 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 13:52:24 +0100 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-outbound-03.txt Date: Fri, 24 Mar 2006 13:52:23 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1BC3@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZPP0CxCt1uPvlhQuaDHqnVVHQg/QAARU5Q From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 24 Mar 2006 12:52:24.0389 (UTC) FILETIME=[CC314F50:01C64F41] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 > What I am saying is: if your outbound proxy is located in the ISP A > network (evil.walled.garden.com), and you do the DNS lookup based on ISP > C (free.and.open.tutpro.com), where your registrar is located, how will > the DNS return the address of a outbound proxy within the > evil.walled.garden.com domain? >i have said already two times that in the default common case, there are no walled gardens or firewalls that would prevent outbound sip traffic. So, why do you need an outbound proxy in the first place??? You simply do a DNS lookup based on the AoR, and receive the address of the registrar - or a proxy in the same domain. This is pure RFC3261/3263 behavior, so I don't see what there is to standardize... I thought the outbound draft is trying to solve the case when you DO have a NAT, or something similar... >>I don't think we can assume that the outbound proxy and the registrar >>are the same thing, or that they are located in the same domain/AoR. >in the default common case we can assume that the registrar and outbound proxy for a domain are the same. So, again, what is there to standardize? >this what most SIP phones on the market assume today and i haven't seen any problems with it. As far as I know, most SIP phones gives you the possibility to configure an outbound proxy, which is completely separate from the AoR where requests are addressed... >i understand that in walled gardens this may not work, but for those environment you are welcome to do something more complicated that the default=20 >operation. In 3GPP the terminals get the address of the P-CSCF using a discovery mechanism, and I believe it works quite well. You don't have to configure the proxy address... 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 Mar 24 08:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmDz-0000zQ-5n; Fri, 24 Mar 2006 08:21:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmDy-0000z6-Fg for sip@ietf.org; Fri, 24 Mar 2006 08:21:06 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMlkH-000539-2a for sip@ietf.org; Fri, 24 Mar 2006 07:50:25 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FMlUV-0004Nk-RM for sip@ietf.org; Fri, 24 Mar 2006 07:34:10 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FMlUT-0001RZ-JM; Fri, 24 Mar 2006 14:34:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17443.59197.537865.833364@harjus.tutpro.com> Date: Fri, 24 Mar 2006 14:34:05 +0200 To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1BBE@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1BBE@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: -2.6 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Christer Holmberg (JO/LMF) writes: > What I am saying is: if your outbound proxy is located in the ISP A > network (evil.walled.garden.com), and you do the DNS lookup based on ISP > C (free.and.open.tutpro.com), where your registrar is located, how will > the DNS return the address of a outbound proxy within the > evil.walled.garden.com domain? i have said already two times that in the default common case, there are no walled gardens or firewalls that would prevent outbound sip traffic. so please stop asking me what to do in your cow milking environment. the default case assumes open internet. > I don't think we can assume that the outbound proxy and the registrar > are the same thing, or that they are located in the same domain/AoR. in the default common case we can assume that the registrar and outbound proxy for a domain are the same. this what most SIP phones on the market assume today and i haven't seen any problems with it. i understand that in walled gardens this may not work, but for those environment you are welcome to do something more complicated that the default operation. -- 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 Fri Mar 24 08:34:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmOk-000284-PG; Fri, 24 Mar 2006 08:32:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmOj-00024v-8x for sip@ietf.org; Fri, 24 Mar 2006 08:32:13 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMmOi-0007t0-UH for sip@ietf.org; Fri, 24 Mar 2006 08:32:13 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FMmOh-0001VP-60; Fri, 24 Mar 2006 15:32:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17443.62683.106257.548564@harjus.tutpro.com> Date: Fri, 24 Mar 2006 15:32:11 +0200 To: Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F021C87AE@esebe103.NOE.Nokia.com> References: <17443.42973.890178.510188@harjus.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F021C87AE@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org, christer.holmberg@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 Erkki.Koivusalo@nokia.com writes: thanks for your constructive email. > - Specify in the Outbound I-D that it would be possible to use > multiple SRV records simultaneously, unlike RFC 2782 states. > Similar handling could possibly be defined for DHCP SIP server > option. if it is allowed to append the tags to SRV result, then we might be able to say that if some specific tag is associated with hostname of proxy, then the proxy is an outbound proxy according to Outbound-ID. otherwise the proxies do not play Outbound game. for example, there could be a tag specifying is the proxy belongs to primary or secondary outbound set. > - Specify a way to derive from the host part of AOR two different > names to resolve with DNS e.g. using a predefined prefix or postfix > to the original domain name to indicate SRV entries for backup > servers. this would also be possible, but it would be better to get everything with a single query. there may still be problem with the tags. > - Rely only to explicit configuration of those proxies e.g. with > configuration framework. I do not like this option too much as > it would cause extra trouble in deployment. Further it would > rely on a standard mechanism that is just not yet available > (or on a proprietary mechanism instead). not good as you say yourself. -- 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 Fri Mar 24 09:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMnND-0000rO-TU; Fri, 24 Mar 2006 09:34:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMnNC-0000rJ-7q for sip@ietf.org; Fri, 24 Mar 2006 09:34:42 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMmZx-0008Js-Ta for sip@ietf.org; Fri, 24 Mar 2006 08:43:49 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FMm9j-0004hJ-IO for sip@ietf.org; Fri, 24 Mar 2006 08:16:44 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 13A761403F1; Fri, 24 Mar 2006 15:16:42 +0200 (EET) Received: from rautu (dhcp7.tutpro.com [192.98.100.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id C2E921403E7; Fri, 24 Mar 2006 15:16:31 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 6986BF15A8; Fri, 24 Mar 2006 15:17:23 +0200 (EET) From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1BC3@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1BC3@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 Message-Id: <20060324131723.6986BF15A8@rautu> Date: Fri, 24 Mar 2006 15:17:23 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: -2.6 (--) 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 Christer Holmberg (JO/LMF) writes: > So, why do you need an outbound proxy in the first place??? You simply > do a DNS lookup based on the AoR, and receive the address of the > registrar - or a proxy in the same domain. This is pure RFC3261/3263 > behavior, so I don't see what there is to standardize... normal SRV lookup does return names of proxies of the domain, but my perhaps poor understanding of outbound is that that is not enough. UA also needs to somehow get the tags, e.g., ";lr;sip-stun" associated with an outbound proxy. i'm not sure if those can be added after hostname in regular SRV reply. > I thought the outbound draft is trying to solve the case when you DO > have a NAT, or something similar... sure, and i don't have any problems with regular NATs. what i said that the common case does not include firewalls or walled gardens that would prevent outbound SIP traffic. NATs don't do so. > So, again, what is there to standardize? see above. how does the UA learn the tags associated with the proxies. if they can be just appended after the hostname in regular SRV lookup, then fine, we don't need to standardize any new protocols. however, the draft MUST mandate that each UA that implement outbound, MUST also implement the lookup as default behavior. > As far as I know, most SIP phones gives you the possibility to configure > an outbound proxy, which is completely separate from the AoR where > requests are addressed... sure, but manual configuration is not a good thing. if we don't want SIP to be ridiculed by skype folks, we need to start taking auto-configuration very seriously. > In 3GPP the terminals get the address of the P-CSCF using a discovery > mechanism, and I believe it works quite well. You don't have to > configure the proxy address... fine, and i want the same for regular SIP UAs and i want it to be such implementation to be mandated by the outbound spec. -- 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 Fri Mar 24 09:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMnaY-0004wG-57; Fri, 24 Mar 2006 09:48:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMnaW-0004sT-Ed for sip@ietf.org; Fri, 24 Mar 2006 09:48:28 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMmZz-0008Js-0k for sip@ietf.org; Fri, 24 Mar 2006 08:43:51 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FMm8h-0004gs-JL for sip@ietf.org; Fri, 24 Mar 2006 08:15:40 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2ODFXGS030215; Fri, 24 Mar 2006 15:15:37 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 15:15:03 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 15:15:02 +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-outbound-03.txt Date: Fri, 24 Mar 2006 15:14:58 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F021C87AE@esebe103.NOE.Nokia.com> In-Reply-To: <17443.42973.890178.510188@harjus.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZPGfdHjN4YdbzBSc6viqqUtd5nkwAHzJvQ From: To: , X-OriginalArrivalTime: 24 Mar 2006 13:15:02.0751 (UTC) FILETIME=[F5D6E6F0:01C64F44] X-Spam-Score: -2.6 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Hi ! My 2 cents: >outbound version 03 still doesn't address auto-discovery of the >outbound-proxy-set. >it must be enough to configure three thing in the UA: username, >password and AoR. the lookup of outbound-proxy-set is done based on >host part of AoR. >so what i'm trying to say that ietf must define DNS based >auto-configuration of outbound-proxy-set for the COMMON case, where >there is a single outbound-proxy-set that is used for all destinations. I must say Juha's request makes very much sense to me. This far it has been possible to discover the outbound proxy by either DNS SRV lookup base on the host part of the AOR or e.g. by using the SIP server option of DHCP, to support the mobility case if the IP connectivity to the proxy server of home domain is not enough. >I don't think we can assume that the outbound proxy and the registrar >are the same thing, or that they are located in the same domain/AoR. Not in all cases, but I do not agree we should give up on creating a solution that would support a very common case (proxies in the home domain) just because it would be difficult to create one solution that would support all possible scenarios / setups. We might well have different mechanisms for different cases. Juha's use case could be supported by DNS SRV query while DHCP could be used for finding local proxies, if that is for some reason preferred. While outbound promotes ways for using multiple connections towards multiple proxies it does not yet address the problem of discovering those proxies in a satisfactory way: The deployment here requires that DNS is configured with one entry that resolves to all the primary hosts and another entry that resolves to all the backup hosts. Designs having only one set were also considered, but in this case there would have to be some way to ensure that the two connection did not accidentally resolve to the same host. Various approaches for this are possible but all probably require extensions to the SIP protocol so they were not included in this specification. Even if there could be two entries in the DNS for resolving primary hosts and backup hosts, there is no hint given how the UA could find or identify those two entries. Using the host part of the AOR according to RFC 3263 leads the UA to possibly find multiple SRV records. However according to RFC 2782 procedures only the preferred one (that responds) should be selected and used. So how to find those multiple proxies then ? - Specify in the Outbound I-D that it would be possible to use multiple SRV records simultaneously, unlike RFC 2782 states. Similar handling could possibly be defined for DHCP SIP server option. - Specify a way to derive from the host part of AOR two different names to resolve with DNS e.g. using a predefined prefix or postfix to the original domain name to indicate SRV entries for backup servers. - Rely only to explicit configuration of those proxies e.g. with configuration framework. I do not like this option too much as it would cause extra trouble in deployment. Further it would=20 rely on a standard mechanism that is just not yet available=20 (or on a proprietary mechanism instead). Any comments or better ideas ? 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 Mar 24 10:08:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMns5-0004ci-1x; Fri, 24 Mar 2006 10:06:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMns3-0004cc-J7 for sip@ietf.org; Fri, 24 Mar 2006 10:06:35 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMns2-0003HL-9l for sip@ietf.org; Fri, 24 Mar 2006 10:06:35 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 2134E3BEF3; Fri, 24 Mar 2006 16:06:33 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11867-01-12; Fri, 24 Mar 2006 16:06:32 +0100 (CET) Received: from dhcp-wavelan-v-37.publik.su.se (dhcp-wavelan-v-37.publik.su.se [193.10.145.37]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id C2D233BEEB; Fri, 24 Mar 2006 16:06:28 +0100 (CET) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Date: Fri, 24 Mar 2006 16:06:06 +0100 User-Agent: KMail/1.9.1 References: <8B1D53AEF7B03449A6D3771B3B7F850F021C87AE@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F021C87AE@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603241606.06251.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.665 tagged_above=-99 required=7 tests=[BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: jh@tutpro.com, christer.holmberg@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 On Friday 24 March 2006 14:14, Erkki.Koivusalo@nokia.com wrote: ... > - Specify a way to derive from the host part of AOR two different > names to resolve with DNS e.g. using a predefined prefix or postfix > to the original domain name to indicate SRV entries for backup > servers. I think this is the way to go for Outbound. The thing is that you might very well want clients in your domain to connect to different SIP servers than you want other domains trying to reach your users to connect to. A real life example : I want people trying to reach my users to look up NAPTR/SRV for 'it.su.se' (naturally) but I want my clients to use other servers, currently indicated by NAPTR/SRV records for 'out.sip.su.se' because these other servers do stuff like Outbound, which the 'it.su.se' servers does not. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 24 10:18:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMo1l-0007aN-VQ; Fri, 24 Mar 2006 10:16:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMo1k-0007aI-HM for sip@ietf.org; Fri, 24 Mar 2006 10:16:36 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMo1i-0003mw-UH for sip@ietf.org; Fri, 24 Mar 2006 10:16:36 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 50B956C017 for ; Fri, 24 Mar 2006 10:16:32 -0500 (EST) Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt From: "Dale R. Worley" To: Sip In-Reply-To: <17443.62683.106257.548564@harjus.tutpro.com> References: <17443.42973.890178.510188@harjus.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F021C87AE@esebe103.NOE.Nokia.com> <17443.62683.106257.548564@harjus.tutpro.com> Content-Type: text/plain Date: Fri, 24 Mar 2006 10:16:32 -0500 Message-Id: <1143213392.14906.38.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 It seems quite reasonable to me to discuss means by which a UA can discover the outbound proxy it needs to contact its registrar, especially in the context of an RFC regarding how to manage connections out through such a proxy. (Though in my experience, the bulk of SIP UAs are used in the internal phone systems of organizations, and the "outbound" connection that is troublesome is the "outgoing trunk" from the PBX registrar/proxy to the rest of the world; communication between the UAs and the registrar/proxy is usually open.) But finding an outbound proxy seems to be inherently dependent on the location of the UA -- If there was one single outbound proxy with a globally reachable address that all UAs attempting to register for a domain could contact, one would point the DNS SRV record for the domain to that address. So whatever mechanism is used to discover the outbound proxy must return different answers to different requesters. In practice, isn't the "outbound proxy" discovered implicitly by the routing outward through the NATs of a packet addressed to the registrar for the domain? And the problem that needs addressing is how the UA can become aware of these NATs and interact with them so as to allow successful incoming communication? Indeed, having used SIP phones both internally to an organization and having a phone at my home connect out through a NAT to register with the SBC that is the DNS SRV address for the organization's domain on the public Internet, I've never had to configure an outgoing proxy. 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 Fri Mar 24 10:26:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMo9A-0004WY-85; Fri, 24 Mar 2006 10:24:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMo99-0004WT-GI for sip@ietf.org; Fri, 24 Mar 2006 10:24:15 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMo98-0004He-7n for sip@ietf.org; Fri, 24 Mar 2006 10:24:15 -0500 Received: from [130.129.131.95] (DHCP-Wireless-131-95.ietf65.org [130.129.131.95]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2OFOi2Y027142 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Mar 2006 09:24:44 -0600 In-Reply-To: <17443.34205.560550.825661@harjus.tutpro.com> References: <17443.34205.560550.825661@harjus.tutpro.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <500994B4-BB9F-4075-B95A-E7505B51658C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Date: Fri, 24 Mar 2006 09:24:27 -0600 To: Juha Heinanen X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Mar 23, 2006, at 11:37 PM, Juha Heinanen wrote: > outbound version 03 still doesn't address auto-discovery of the > outbound-proxy-set. as i have said in before, the specification is in > practise useless and should not be published as an RFC unless there > is a > standard (preferably DNS based way) to do so. > > -- juha Perhaps we need a SIPPING draft on "basic configuration" or something that would represent best current practices? Or is there a SIP extension needed to support your 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 Fri Mar 24 10:35:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoIJ-00089J-De; Fri, 24 Mar 2006 10:33:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoII-00086H-Br for sip@ietf.org; Fri, 24 Mar 2006 10:33:42 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMoIH-0004ii-29 for sip@ietf.org; Fri, 24 Mar 2006 10:33:42 -0500 Received: from [130.129.131.95] (DHCP-Wireless-131-95.ietf65.org [130.129.131.95]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2OFY9nx027193 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Mar 2006 09:34:10 -0600 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1BB7@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1BB7@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Date: Fri, 24 Mar 2006 09:33:52 -0600 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, 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 On Mar 24, 2006, at 3:49 AM, Christer Holmberg ((JO/LMF)) wrote: > What if both ISP A and ISP B have an outbound proxy, and you do > your DNS > lookup based on the AoR of the registrar in ISP C. Again, will you use > private ISP A DNS servers (or private ISP B DNS servers) in order to > find the appropirate outbound proxy? I think Juha's point may be that if ISP A and ISP B are really ISPs, as supposed to "IMS operators" or "VoISP operators that also provide an IP access network that really isn't the Internet", then nothing prevents him from talking directly to the service platform of C (which is in my terms a VoISP, not an ISP. In the conventional ISP case (which is not the more complex "general" case we've been working on), this is the case. Now, if one leaves the confines of a conventional ISP and roams onto a private network operated by an enterprise with a proxy-enabled firewall, the "talk directly to VoISP C" approach won't work. This is actually pretty much consistent with the augmented 3261 procedure: 1) If you have an outbound proxy configured, use that. Exit. 2) If your DHCP informs you of an outbound proxy, use that. Exit. 3) If there is a default proxy configured, use that. Exit. 4) Use the domain of your AOR to do a lookup ala 3263, and if that resolves, use it. Exit. 5) Fail. I think what Juha is suggesting could perhaps be accommodated by a draft detailing the above common practice. This wouldn't be in-scope for SIP, but would be (I believe) for SIPPING. -- 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 Mar 24 10:41:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoOB-00065q-Ut; Fri, 24 Mar 2006 10:39:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoOA-00065l-OZ for sip@ietf.org; Fri, 24 Mar 2006 10:39:46 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMoO6-0004yQ-CO for sip@ietf.org; Fri, 24 Mar 2006 10:39:46 -0500 Received: by tutpro.com (Postfix, from userid 65534) id E10761403F1; Fri, 24 Mar 2006 17:39:40 +0200 (EET) Received: from rautu (dhcp7.tutpro.com [192.98.100.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 6B40C1403E7; Fri, 24 Mar 2006 17:39:31 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id B7A10F15A8; Fri, 24 Mar 2006 17:40:22 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17444.4838.686847.862557@rautu.tutpro.com> Date: Fri, 24 Mar 2006 17:40:22 +0200 From: Juha Heinanen To: "Dale R. Worley" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <1143213392.14906.38.camel@cdhcp139.pingtel.com> References: <17443.42973.890178.510188@harjus.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F021C87AE@esebe103.NOE.Nokia.com> <17443.62683.106257.548564@harjus.tutpro.com> <1143213392.14906.38.camel@cdhcp139.pingtel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-4.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 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 Dale R. Worley writes: > Indeed, having used SIP phones both internally to an organization and > having a phone at my home connect out through a NAT to register with the > SBC that is the DNS SRV address for the organization's domain on the > public Internet, I've never had to configure an outgoing proxy. yes, and now we want the same ease to discover Outbound I-D outbound proxies (and to automatically find out if outbound proxies really are implementing Outbound I-D). -- 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 Fri Mar 24 10:44:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoR5-0006hW-Cc; Fri, 24 Mar 2006 10:42:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoR4-0006hR-B7 for sip@ietf.org; Fri, 24 Mar 2006 10:42:46 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMoR2-00057I-WE for sip@ietf.org; Fri, 24 Mar 2006 10:42:46 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 6D62E1403F1; Fri, 24 Mar 2006 17:42:44 +0200 (EET) Received: from rautu (dhcp7.tutpro.com [192.98.100.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 1D1D01403E7; Fri, 24 Mar 2006 17:42:35 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 965BCF15A8; Fri, 24 Mar 2006 17:43:26 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17444.5022.559809.34934@rautu.tutpro.com> Date: Fri, 24 Mar 2006 17:43:26 +0200 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <500994B4-BB9F-4075-B95A-E7505B51658C@softarmor.com> References: <17443.34205.560550.825661@harjus.tutpro.com> <500994B4-BB9F-4075-B95A-E7505B51658C@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-4.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Dean Willis writes: > Perhaps we need a SIPPING draft on "basic configuration" or something > that would represent best current practices? yes, it may be best practise, if nothing new needs to be standardized. the requirements for the DNS query result are: - it tells to UA if outbound proxies implement Outbound I-D and - if so, it somehow conveys to the UA the proxy tags. -- 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 Fri Mar 24 10:57:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FModr-0006bw-37; Fri, 24 Mar 2006 10:55:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FModq-0006br-II for sip@ietf.org; Fri, 24 Mar 2006 10:55:58 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FModp-0005lz-76 for sip@ietf.org; Fri, 24 Mar 2006 10:55:58 -0500 Received: from [130.129.131.95] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2OFuQUP027520 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Mar 2006 09:56:28 -0600 In-Reply-To: <17444.5022.559809.34934@rautu.tutpro.com> References: <17443.34205.560550.825661@harjus.tutpro.com> <500994B4-BB9F-4075-B95A-E7505B51658C@softarmor.com> <17444.5022.559809.34934@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <70E5D965-7AF7-4FD7-B6F6-3AB13AF4CA28@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Date: Fri, 24 Mar 2006 09:56:08 -0600 To: Juha Heinanen X-Mailer: Apple Mail (2.746.3) 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 On Mar 24, 2006, at 9:43 AM, Juha Heinanen wrote: > Dean Willis writes: > >> Perhaps we need a SIPPING draft on "basic configuration" or something >> that would represent best current practices? > > yes, it may be best practise, if nothing new needs to be standardized. > the requirements for the DNS query result are: > > - it tells to UA if outbound proxies implement Outbound I-D and > - if so, it somehow conveys to the UA the proxy tags. Ok, I think we've boiled this down to a new requirement: for the "outbound" technique to work, we MUST have a means of discovering whether a proxy supports the extensions of outbound. While we could do that by doing a REGISTER exchange that includes an appropriate option-tag in Require:, it would be more efficient if the proxy discovery mechanism informed us of this detail. So, we posit that the Outbound draft SHOULD select and discuss such a mechanism. Possible alternatives: 1) Deducing from the proxy URL that it supports Outbound. This potentially works with DNS, DHCP, and configured discovery, but might just be a little too weird with our existing syntax and conventions. 2) Using a different service record in DNS, which works for DNS but not DHCP or configured use cases, I think. We have any other techniques that have been proposed here that I have missed? -- 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 Mar 24 11:38:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpHU-0006FU-0v; Fri, 24 Mar 2006 11:36:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpHO-00066H-8U for sip@ietf.org; Fri, 24 Mar 2006 11:36:50 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMp9Q-0007Lo-EF for sip@ietf.org; Fri, 24 Mar 2006 11:28:36 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2OGR3p4020135; Fri, 24 Mar 2006 18:27:06 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 18:28:32 +0200 Received: from [10.241.58.202] ([10.241.58.202]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Mar 2006 18:28:30 +0200 Message-ID: <44241E2C.2030709@nokia.com> Date: Fri, 24 Mar 2006 18:28:28 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Dean Willis Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt References: <17443.34205.560550.825661@harjus.tutpro.com> <500994B4-BB9F-4075-B95A-E7505B51658C@softarmor.com> <17444.5022.559809.34934@rautu.tutpro.com> <70E5D965-7AF7-4FD7-B6F6-3AB13AF4CA28@softarmor.com> In-Reply-To: <70E5D965-7AF7-4FD7-B6F6-3AB13AF4CA28@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2006 16:28:30.0452 (UTC) FILETIME=[FC918340:01C64F5F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org, 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 ext Dean Willis wrote: > Possible alternatives: > > 1) Deducing from the proxy URL that it supports Outbound. This > potentially works with DNS, DHCP, and configured discovery, but might > just be a little too weird with our existing syntax and conventions. > > 2) Using a different service record in DNS, which works for DNS but not > DHCP or configured use cases, I think. > > We have any other techniques that have been proposed here that I have > missed? 3) The proxy corresponding to the entry in the SRV record of a domain, inspects the Supported of an incoming request for the "outbound" token, and if it exists, redirects the request either with a new 3xx "connect to all of these", or use 300 with new bits that indicate this new semantic. 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 Mar 24 11:42:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpKq-00006s-2O; Fri, 24 Mar 2006 11:40:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpHN-000636-Lj; Fri, 24 Mar 2006 11:36:49 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMp9t-0007Q5-BF; Fri, 24 Mar 2006 11:29:08 -0500 Received: from [130.129.129.164] (DHCP-Wireless-129-164.ietf65.org [130.129.129.164]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2OGQEQM039971 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Mar 2006 10:26:16 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03A46163-DFB6-4B76-8473-BF187AF4ED65@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Fri, 24 Mar 2006 10:26:22 -0600 To: Robert Sparks X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 130.129.129.164 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "sip@ietf.org WG" , sip-implementors@cs.columbia.edu, Sipping WG , "simple@ietf.org list" Subject: [Sip] SIPit 18 Registration closes in 7 days X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Registration for SIPit 18 closes March 31 (7 days from now). If you are planning to attend, but have not already registered, do so now. (if circumstances are forcing you to wait until the last minute, please drop me a note. Late registrations are going to be difficult to accept). Thanks, RjS On Feb 6, 2006, at 11:42 PM, Robert Sparks wrote: > Registration for SIPit 18 is open. > > This event will be held April 17-21 in > Akihabara, Tokyo, Japan. More information > about the event is available at http://www.sipit.net > and the host website at http://www.nic.ad.jp/en/sipit18/ > > Registration will close March 31. Please register early. > You can register now using https://www.regonline.com/88905 > > This 18th SIPForum SIPit is > > Hosted by: > - Japan Network Information Center (JPNIC) > > Co-hosted by: > - WIDE Project > - VoIP System Interoperability Task Force > > Supported by: > - Ministry of Internal Affairs and Communications (MIC) > - The Telecommunication Technology Committee (TTC) > - Telecom Service Association (TELESA) > - VoIP Forum Japan (VFJ) > - IPv6 Promotion Council (v6PC) > - ENUM Trial Japan (ETJP) > > Sponsors: > - Cisco Systems, Inc. > - Fractalist Inc. > - Fusion Communications Corporation > - Japan Telecom Co., Ltd. > - KDDI Corporation > - Mitsubishi Electric Information Network Corporation > - Mitsubishi Research Institute, Inc. > - NEC Corporation > - Netmarks Inc. > - Nippon Telegraph and Telephone Corporation > - Nippon Telegraph and Telephone East Corporation > - Nippon Telegraph and Telephone West Corporation > - NTT Advanced Technology Corporation > - Oki Electric Industry Co., Ltd. > - SoftBank BB Corp. > - Softfront > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 24 19:53:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMwzk-000471-8b; Fri, 24 Mar 2006 19:51:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMwzi-00046w-RX for sip@ietf.org; Fri, 24 Mar 2006 19:51:06 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMwzh-0003J7-KP for sip@ietf.org; Fri, 24 Mar 2006 19:51:06 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2P0p4t9024817 for ; Fri, 24 Mar 2006 18:51:04 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 25 Mar 2006 00:51:04 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB012749189@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Sat, 25 Mar 2006 00:51:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Sip] draft-ietf-sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 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 chair) As a result of the face-to-face meeting held at IETF #65, we agreed in the room on the keepalive mechanism: - OS TCP KeepAlive should be used if the client supports it. - Need something more because OS TCP KeepAlive is not supported in every client OS. - Consensus to use STUN for UDP - Consensus to use STUN for TCP, with use of OS TCP keep alive above. With these agreements the meeting also agreed that the document was ready for WGLC. As a result of this Rohan has produced: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt Unfortunately one of the agreements was left out of this update, and a number of NITS have also been identified. Required Actions: 1) Authors: Produce -04 version to take account of remaining issues where consensus exists and any NITS. 2) Working group: Any dissent to the agreements listed above or do we have rough consensus to proceed according to the agreements made in the meeting 3) Working group: Are we ready to move to WGLC. Please indicate if you consider this document needs more work preceding WGLC. Pleaswe complete all these actions by 31st March 2006. regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 24 21:38:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMydu-0007cs-8f; Fri, 24 Mar 2006 21:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMyds-0007Zg-Vt for sip@ietf.org; Fri, 24 Mar 2006 21:36:40 -0500 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMydr-0007S4-Mc for sip@ietf.org; Fri, 24 Mar 2006 21:36:40 -0500 Received: from [192.168.1.101] (pool-70-17-203-185.balt.east.verizon.net [70.17.203.185]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k2P2aZA30437; Fri, 24 Mar 2006 20:36:35 -0600 Subject: Re: [Sip] draft-ietf-sip-outbound From: "Frank W. Miller" To: "Drage, Keith (Keith)" In-Reply-To: <475FF955A05DD411980D00508B6D5FB012749189@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB012749189@en0033exch001u.uk.lucent.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Fri, 24 Mar 2006 21:36:32 -0500 Message-Id: <1143254192.2712.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit 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 Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Sat, 2006-03-25 at 00:51 +0000, Drage, Keith (Keith) wrote: > (as chair) > > As a result of the face-to-face meeting held at IETF #65, we agreed in the room on the keepalive mechanism: > > - OS TCP KeepAlive should be used if the client supports it. > - Need something more because OS TCP KeepAlive is not supported in every client OS. > - Consensus to use STUN for UDP > - Consensus to use STUN for TCP, with use of OS TCP keep alive above. > > 2) Working group: Any dissent to the agreements listed above or do we have rough consensus to proceed according to the agreements made in the meeting > I have dissent on the use of STUN exclusively for keepalive. I believe that a SIP based mechanism such as the PING draft I proposed is a better solution. The essence of my objection is that I think it is a mistake to have both STUN and SIP residing on the same port. I think this makes little sense for three reasons: 1) its architecturally in conflict with the way most other protocols are defined, i.e. each protocol generally lives on its own port, 2) it unnecessarily complicates implementations when there is a very simple way to do it within SIP, and most importantly 3) it is going to make it very difficult to use STUN for the same task with other protocols that will need keepalives. Also, I don't believe that the performance issues that have been put forth are substantive enough to cause the architectural violations that result from using STUN this way. If the group is dead set on using STUN this way, the SIP way should at least be acknowledged by 1) including a ;keepalive=ping tag for the URI in the outbound draft and 2) allowing the PING draft to become an ietf draft. These actions place very little additional burden on implementors and will allow the "market" to decide which is the right one to be used operationally. Dissent registered. 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 Fri Mar 24 23:33:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN0R9-0004uT-T3; Fri, 24 Mar 2006 23:31:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN0R8-0004uO-2l for sip@ietf.org; Fri, 24 Mar 2006 23:31:38 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FN0R6-0003Sq-P3 for sip@ietf.org; Fri, 24 Mar 2006 23:31:38 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FN0R5-0000iS-Fh; Sat, 25 Mar 2006 06:31:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17444.51111.399581.5005@harjus.tutpro.com> Date: Sat, 25 Mar 2006 06:31:35 +0200 To: "Drage, Keith (Keith)" Subject: [Sip] draft-ietf-sip-outbound In-Reply-To: <475FF955A05DD411980D00508B6D5FB012749189@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB012749189@en0033exch001u.uk.lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 Drage, Keith (Keith) writes: > 3) Working group: Are we ready to move to WGLC. Please indicate if > 3) you consider this document needs more work preceding WGLC. see ongoing discussion on auto-discovery of outbound-proxy-set. the document is not useful in practise without such a mechanism and you cannot thus declare it out of scope. -- 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 Sat Mar 25 05:37:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN66k-0003N7-53; Sat, 25 Mar 2006 05:34:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN66i-0003M7-QT for sip@ietf.org; Sat, 25 Mar 2006 05:34:56 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FN66h-0000Zk-F0 for sip@ietf.org; Sat, 25 Mar 2006 05:34:56 -0500 Received: (qmail 29672 invoked by uid 0); 25 Mar 2006 10:34:54 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 Mar 2006 10:34:54 -0000 Message-ID: <002601c64ff7$be703960$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Drage, Keith \(Keith\)" , References: <475FF955A05DD411980D00508B6D5FB012749189@en0033exch001u.uk.lucent.com> Subject: Re: [Sip] draft-ietf-sip-outbound Date: Sat, 25 Mar 2006 11:34:49 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 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 > 3) Working group: Are we ready to move to WGLC. Please indicate if you > consider this document needs more work preceding WGLC. Several comments: 3.4 - The case where a NAT device would be between the edge proxy and the registrar is out of scope? If so, this could be explicitly written. If not, there is more work to do... 4.4.1 - In addition to checking for 'keepalive=stun', suggestion to also check for 'Supported: outbound' in the OK response to REGISTER. This would avoid misconfiguration scenario's in which the UAC starts poking STUN packets at a registrar that does not expect them. In fact, perhaps the check for Supported alone would be sufficient (and omit keepalive=stun altogether) 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 Sat Mar 25 12:41:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNCjF-0005uq-8h; Sat, 25 Mar 2006 12:39:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNCjD-0005rl-Kv for sip@ietf.org; Sat, 25 Mar 2006 12:39:07 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNCjD-0000Vy-Bv for sip@ietf.org; Sat, 25 Mar 2006 12:39:07 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2PHd5uC004942; Sat, 25 Mar 2006 11:39:06 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 25 Mar 2006 17:39:05 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0127491A6@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Juha Heinanen Subject: RE: [Sip] draft-ietf-sip-outbound Date: Sat, 25 Mar 2006 17:38:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 chair) I was not aware that either of the chairs had declared anything out of scope, as yet. Firstly the question asked of the list is a very standard question with the aim of getting people to identify outstanding issues. If those issues do not get posted, then we make no progress at all on any document. You have done that. However we are working to get this document out of the door. We are past the charter milestone when we agreed it would be finished by, so we are pushing for rapid resolution of any issues. Therefore we would ask all posters to be very clear in indicating what they see as the way forward on any issue, and how this should be documented. This document is intended to be standards track. The postings at the moment seem to indicate that the solution to the issue you raise may well be dependent on how outbound is deployed in any architecture, which would imply a separate BCP document, or at least non-standards track document, covering those issues, rather than coverage in draft-ietf-sip-outbound itself. I would therefore like to see posters covering issues such as: - Can we separate out this issue into a BCP - If yes, is there a member of the SIP or SIPPING WG who is prepared to put together a draft and submit. - If yes, what are the interdependencies between draft-ietf-sip-outbound and this proposed draft. - and of course as always: "send text". and of course, if you consider we don't need to do anything at all on this issue, then please indicate that as well. We set a deadline of 31st March to establish what the issues are that prevent WGLC. At that time, the chairs will ascertain whether WGLC can be started, and on what version of the document. We have already indicated that a -04 version will need to be produced for that intended WGLC. regards Keith > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: 25 March 2006 04:32 > To: Drage, Keith (Keith) > Cc: sip@ietf.org > Subject: [Sip] draft-ietf-sip-outbound > > > Drage, Keith (Keith) writes: > > > 3) Working group: Are we ready to move to WGLC. Please indicate if > > 3) you consider this document needs more work preceding WGLC. > > see ongoing discussion on auto-discovery of outbound-proxy-set. the > document is not useful in practise without such a mechanism and you > cannot thus declare it out of scope. > > -- 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 Sat Mar 25 13:08:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FND9e-0004IA-V9; Sat, 25 Mar 2006 13:06:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FND9d-0004I5-VT for sip@ietf.org; Sat, 25 Mar 2006 13:06:25 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FND9c-0001R7-Ih for sip@ietf.org; Sat, 25 Mar 2006 13:06:25 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 62B2C13F990; Sat, 25 Mar 2006 20:06:23 +0200 (EET) Received: from rautu (dhcp7.tutpro.com [192.98.100.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 3711113F988; Sat, 25 Mar 2006 20:06:18 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 917E5F15A8; Sat, 25 Mar 2006 20:07:08 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17445.34507.784544.474685@rautu.tutpro.com> Date: Sat, 25 Mar 2006 20:07:07 +0200 From: Juha Heinanen To: "Drage, Keith (Keith)" Subject: RE: [Sip] draft-ietf-sip-outbound In-Reply-To: <475FF955A05DD411980D00508B6D5FB0127491A6@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0127491A6@en0033exch001u.uk.lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 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 Drage, Keith (Keith) writes: > - Can we separate out this issue into a BCP definitely not. i have specifically asked for a mechanism to detect outbound-proxy-set in the common default case, where outbound proxies are freely reachable from the SIP UAs, i.e., for the case where there are no firewall or SBCs that would block outbound SIP traffic. i'm not asking anything else than what SRV lookup provides for outbound proxies according to rfc3263. we MUST extend that mechanism in order for the SIP UA to learn that (1) proxies implement outbound I-D and (2) that they also learn the tags. > - If yes, is there a member of the SIP or SIPPING WG who is > - prepared to put together a draft and submit. there is NO POINT to publish the outbound I-D as rfc BEFORE the above discussed mechanism is in place, because it is FAR TOO MUCH work for users to enter outbound-proxy-set information manually. it is high time to make SIP more user friendly than it currently is. you must have lived far too long in the abstract IETF world if you want to push this kind manual burden to the users. how about working for a service provider for a few years? > - If yes, what are the interdependencies between > - draft-ietf-sip-outbound and this proposed draft. the proposed draft tells what kind of DNS query SIP UA makes in order to learn the two NEW pieces of information that outbound i-d needs on top of regular SRV query defined in rfc 3263. rfc 3261 refers to rfc 3263 for server discovery and this new I-D MUST refer to a successor of rfc 3263. -- 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 Sat Mar 25 16:27:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNGGQ-0007CF-2p; Sat, 25 Mar 2006 16:25:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNGGO-0007CA-VX for sip@ietf.org; Sat, 25 Mar 2006 16:25:36 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNGGN-0001Ee-LO for sip@ietf.org; Sat, 25 Mar 2006 16:25:36 -0500 Received: from [192.168.2.100] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2PLQ6gj001025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Mar 2006 15:26:07 -0600 Message-ID: <4425B5C6.7070003@softarmor.com> Date: Sat, 25 Mar 2006 15:27:34 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] draft-ietf-sip-outbound References: <475FF955A05DD411980D00508B6D5FB0127491A6@en0033exch001u.uk.lucent.com> <17445.34507.784544.474685@rautu.tutpro.com> In-Reply-To: <17445.34507.784544.474685@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Juha Heinanen wrote: > Drage, Keith (Keith) writes: > > > - Can we separate out this issue into a BCP > > definitely not. i have specifically asked for a mechanism to detect > outbound-proxy-set in the common default case, where outbound proxies > are freely reachable from the SIP UAs, i.e., for the case where there > are no firewall or SBCs that would block outbound SIP traffic. i'm not > asking anything else than what SRV lookup provides for outbound proxies > according to rfc3263. we MUST extend that mechanism in order for > the SIP UA to learn that (1) proxies implement outbound I-D and (2) that > they also learn the tags. > > > - If yes, is there a member of the SIP or SIPPING WG who is > > - prepared to put together a draft and submit. > > there is NO POINT to publish the outbound I-D as rfc BEFORE the above > discussed mechanism is in place, because it is FAR TOO MUCH work for > users to enter outbound-proxy-set information manually. it is high time > to make SIP more user friendly than it currently is. you must have > lived far too long in the abstract IETF world if you want to push this > kind manual burden to the users. how about working for a service > provider for a few years? > > > - If yes, what are the interdependencies between > > - draft-ietf-sip-outbound and this proposed draft. > > the proposed draft tells what kind of DNS query SIP UA makes in order to > learn the two NEW pieces of information that outbound i-d needs on top > of regular SRV query defined in rfc 3263. rfc 3261 refers to rfc 3263 > for server discovery and this new I-D MUST refer to a successor of rfc > 3263. I don't suppose you could send text? If it looks OK, Cullen would probably be able to paste it into the next rev for WGLC. If it doesn't fit into the "outbound" draft well, the text would still give us a good basis for a new draft that would extend RFC 3263. -- 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 Mar 25 16:29:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNGIB-0001MR-A8; Sat, 25 Mar 2006 16:27:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNGIA-0001MM-Jk for sip@ietf.org; Sat, 25 Mar 2006 16:27:26 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNGIA-0001Ko-AZ for sip@ietf.org; Sat, 25 Mar 2006 16:27:26 -0500 Received: from [192.168.2.100] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2PLRw5S001033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Mar 2006 15:27:58 -0600 Message-ID: <4425B635.5070107@softarmor.com> Date: Sat, 25 Mar 2006 15:29:25 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org References: <17443.34205.560550.825661@harjus.tutpro.com> <500994B4-BB9F-4075-B95A-E7505B51658C@softarmor.com> <17444.5022.559809.34934@rautu.tutpro.com> <70E5D965-7AF7-4FD7-B6F6-3AB13AF4CA28@softarmor.com> In-Reply-To: <70E5D965-7AF7-4FD7-B6F6-3AB13AF4CA28@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Juha Heinanen Subject: [Sip] How to indicate during proxy discovery that a proxy supports "outbound" X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > > On Mar 24, 2006, at 9:43 AM, Juha Heinanen wrote: > >> Dean Willis writes: >> >>> Perhaps we need a SIPPING draft on "basic configuration" or something >>> that would represent best current practices? >> >> >> yes, it may be best practise, if nothing new needs to be standardized. >> the requirements for the DNS query result are: >> >> - it tells to UA if outbound proxies implement Outbound I-D and >> - if so, it somehow conveys to the UA the proxy tags. > > > Ok, I think we've boiled this down to a new requirement: > > for the "outbound" technique to work, we MUST have a means of > discovering whether a proxy supports the extensions of outbound. > > While we could do that by doing a REGISTER exchange that includes an > appropriate option-tag in Require:, it would be more efficient if the > proxy discovery mechanism informed us of this detail. So, we posit that > the Outbound draft SHOULD select and discuss such a mechanism. > > Possible alternatives: > > 1) Deducing from the proxy URL that it supports Outbound. This > potentially works with DNS, DHCP, and configured discovery, but might > just be a little too weird with our existing syntax and conventions. > > 2) Using a different service record in DNS, which works for DNS but not > DHCP or configured use cases, I think. > > We have any other techniques that have been proposed here that I have > missed? Anybody have some furtehr ideas on 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 From sip-bounces@ietf.org Sat Mar 25 16:55:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNGhA-0001FI-0M; Sat, 25 Mar 2006 16:53:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNGh9-0001FD-EQ for sip@ietf.org; Sat, 25 Mar 2006 16:53:15 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNGh9-0002C5-17 for sip@ietf.org; Sat, 25 Mar 2006 16:53:15 -0500 Received: (qmail 6730 invoked by uid 0); 25 Mar 2006 21:53:13 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 Mar 2006 21:53:13 -0000 Message-ID: <002201c65056$80ac1a90$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dean Willis" , References: <17443.34205.560550.825661@harjus.tutpro.com> <500994B4-BB9F-4075-B95A-E7505B51658C@softarmor.com> <17444.5022.559809.34934@rautu.tutpro.com><70E5D965-7AF7-4FD7-B6F6-3AB13AF4CA28@softarmor.com> <4425B635.5070107@softarmor.com> Subject: Re: [Sip] How to indicate during proxy discovery that a proxy supports"outbound" Date: Sat, 25 Mar 2006 22:53:08 +0100 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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: 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 Dean, Could you explain why it is needed that the UA knows whether the proxy supports outbound before sending its REGISTER request? With 'lr' this is clear: the UA must formulate the request differently (i.e. request URI / Route swap). But when a UA sends a REGISTER with reg-id etc, it seems that the worst thing that could happen is that the response does not contain 'Supported: outbound' (but otherwise succeeds). Regards, jeroen ----- Original Message ----- From: "Dean Willis" To: Cc: "Juha Heinanen" Sent: Saturday, March 25, 2006 10:29 PM Subject: [Sip] How to indicate during proxy discovery that a proxy supports"outbound" > Dean Willis wrote: >> >> On Mar 24, 2006, at 9:43 AM, Juha Heinanen wrote: >> >>> Dean Willis writes: >>> >>>> Perhaps we need a SIPPING draft on "basic configuration" or something >>>> that would represent best current practices? >>> >>> >>> yes, it may be best practise, if nothing new needs to be standardized. >>> the requirements for the DNS query result are: >>> >>> - it tells to UA if outbound proxies implement Outbound I-D and >>> - if so, it somehow conveys to the UA the proxy tags. >> >> >> Ok, I think we've boiled this down to a new requirement: >> >> for the "outbound" technique to work, we MUST have a means of >> discovering whether a proxy supports the extensions of outbound. >> >> While we could do that by doing a REGISTER exchange that includes an >> appropriate option-tag in Require:, it would be more efficient if the >> proxy discovery mechanism informed us of this detail. So, we posit that >> the Outbound draft SHOULD select and discuss such a mechanism. >> >> Possible alternatives: >> >> 1) Deducing from the proxy URL that it supports Outbound. This >> potentially works with DNS, DHCP, and configured discovery, but might >> just be a little too weird with our existing syntax and conventions. >> >> 2) Using a different service record in DNS, which works for DNS but not >> DHCP or configured use cases, I think. >> >> We have any other techniques that have been proposed here that I have >> missed? > > Anybody have some furtehr ideas on 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 Sat Mar 25 22:02:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNLUV-0008QO-0M; Sat, 25 Mar 2006 22:00:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNLUT-0008Ml-6c for sip@ietf.org; Sat, 25 Mar 2006 22:00:29 -0500 Received: from [12.18.100.162] (helo=IPOfCard1.guest-tek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNLUS-0005Ql-Ko for sip@ietf.org; Sat, 25 Mar 2006 22:00:29 -0500 Received: from jys3105061846 (localhost.localdomain [127.0.0.1]) by IPOfCard1.guest-tek.com (8.11.6/8.11.6) with ESMTP id k2Q30FE29445; Sat, 25 Mar 2006 20:00:15 -0700 From: "Rocky Wang" To: "'Shida Schubert'" Subject: RE: [Sip] draft-cao-sip-response-identity-00 anddraft-elwell-sip-connected-identity-01 Date: Sat, 25 Mar 2006 21:00:19 -0600 Message-ID: <004901c65081$6c530060$d7a912c6@china.huawei.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: <4421F997.8090505@ntt-at.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcZOGVfAh25RRyqQQnCUx0hqKy9FRQBOtmBA X-Spam-Score: 1.1 (+) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: sip@ietf.org, "'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 I suggest to merge the two draft together does not mean I want you to accept cao's solution. Bur from the requirement viewpoint, I suggest we should do so. And see below inline, please: > -----Original Message----- > From: [mailto:shida@ntt-at.com] > Sent: Wednesday, March 22, 2006 7:28 PM > To: Rocky Wang > Cc: 'Elwell, John'; sip@ietf.org > Subject: Re: [Sip] draft-cao-sip-response-identity-00 > anddraft-elwell-sip-connected-identity-01 > Shida Schubert wrote: > > Hi Rocky; > > Why do you want the response identity so bad? Really I don't want the response identify BAD! When you read the documents as the session order, you will find that the requirements are overlapped and it is easy for anybody to get a conclusion that we should merge them into one. That is, anyone goes forward a little, it will be esay to conver the requirement in another. And it is nature that we can use the UPDATE and re-INVITE to update the local identity identifier. I don't anybody hold another opinion on this. Why we need an extension header or mechanism for this part of requirement? Just like Cullen Jennings said in IETF64, the implementator will fall into confusion because he don't know where it should get the peer identifier. There is no any problem for anyone using his owner mechanism, but what about for others? It already goes so difficult till now and I can't imagine what it will be tomorrow. For each one, it looks like simple enough, but if you consider them all together, how complex it is now! > - As I understand there are two issues, response identity > is trying to solve. > Issue 1. Who am I really connected to and is it really who > it claims it is? > - Connected Identity solves this problem by allowing the > changes in From header > field and re-using the SIP-Identity spec. The > Connected-Identity spec is nice > because it reuses what's already there and does not > introduce any new header for > indicating identity. And inherit all the nice traits > identity header provides such as > integrity etc. > - Response Identity tries to provide the same thing by > introducing few new headers > which clutters the header with more Identity related > information. > Beside there are > few issues with how one should trust the > response-identity(Proxy unable to authorize > the response etc.). I really don't want to deny your extension at all, but we should consider the reqirements together but not seperated. It is the same thing for your two drafts but different case, one is for successful calls and another include failure flows as well. I would like to know what's your opinion. I also know that the meeting has already get a consensus for your draft, but I want to have a discussion on if it is possible put the provisional, successful, redirecting and failure cases together from the ML. > > Issue 2. Am I connected to foo as a result of routing > decision based on my INVITE? > - Can't really solve the issue with neither of the > solution described above. > > Issue 2 can't be solved by neither of the solution and > Issue 1 can be solved with > Connected Identity without adding any extra identity > related header. > So I personally > don't know why you are so persistent with adopting them > both? I think > Connected-Identity alone satisfies what the WG wants, but > I could be completely > wrong. I have expressed my opinion above already. > > As for other reason why I don't think they should merge, > currently they propose two > completely different solution to address the same problem > yet at different timing. Firstly, the requirements in the two drafts are really can be merged. And for the solution, we should have a more discussion on it. No body wants to accept two mechanisms to resolve the same problem in these two different simillar cases, I think. I have consensus with your solution. I would like choose change the To-URI if both UAC and UAS support to change the From and To URI, otherwise maybe P-Asserted-Identity header is fit on this. I suggest to merge the two draft together does not mean I want you to accept cao's solution. Bur from the requirement viewpoint, I suggest we should do so. > > And let's not forget, merging the work would create > dependency on each spec and > results in creating a delays in overall progress. I have > been hearing that WG wants to > resolve Issue 1, in which case delay due to the merge is > likely to be unacceptable. Why it is impossible to merge the requirement togher? > > Regards > Shida Schubert > > Rocky Wang wrote: > > I agree with you that there are some requirements to convey the > > changed identifier. But I think UPDATE and re-INVITE can be > used to do > > so, that is no need to create a 2nd solution. > > Apart from the mid-dialog requiements, the Connect-URI can be > > considered as a sub-set of the response identifier. Today we are > > discussing about conveying the connected URI that return > the response, > > tomorrow, maybe we must re-consider how to convey the > identifier which > > return responses and then we must do the same thing again, > including > > the security and some other problems. > > What I want to say is that the two drafts can be merged easily from > > the requirement and expected solution aspects because they are > > overlapped with each other, and we should do so as my owner opinion. > > > > Rocky Wang > > > > > > > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens.com] > >> Sent: Wednesday, March 22, 2006 12:45 PM > >> To: Rocky Wang; sip@ietf.org > >> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > >> draft-elwell-sip-connected-identity-01 > >> > >> Rocky, > >> > >> The connected-identity draft already gives two examples why a > >> mid-dialog change would be needed: PSTN gateway and B2BUA. > >> > >> We could define a new header field for response identity > if this can > >> be justified, but it would not be secure. I think the consensus > >> yesterday was to move forward with connected-identity and consider > >> separately whether response identity is achievable in a > way that is > >> secure as well as adding some value in certain use cases. > >> > >> John > >> > >> > >> > >>> -----Original Message----- > >>> From: Rocky Wang [mailto:rocky.wang@huawei.com] > >>> Sent: 22 March 2006 14:44 > >>> To: Elwell, John; sip@ietf.org > >>> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > >>> draft-elwell-sip-connected-identity-01 > >>> > >>> As my opinion, they two just need take the responser > identifier in > >>> the response messages. We must consider and resolve all > the problem > >>> include the security problems in both cases. > >>> If you want to indicate a change of party mid-dialog, you > >>> > >> can use some > >> > >>> mid-dialog method to do it, as I considered, just like UPDATE and > >>> re-INVITE. > >>> That's not so difficult in use of exist mechanism. But can > >>> > >> you please > >> > >>> give me an application case of the usage of mid-dialog entity > >>> identifier indication. > >>> > >>> -----Original Message----- > >>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>> Sent: Tuesday, March 21, 2006 11:44 PM > >>> To: Rocky Wang; sip@ietf.org > >>> Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > >>> draft-elwell-sip-connected-identity-01 > >>> > >>> Rocky, > >>> > >>> The connected-identity draft is not a subset of the > >>> > >> response identity > >> > >>> draft. > >>> The response identity draft cannot be used to indicate a > change of > >>> party mid-dialog. > >>> > >>> I don't think we can merge them. There was no consensus on the > >>> response identity draft. The following views have been expressed: > >>> - that it does not provide any benefit; > >>> - that the response identity problem cannot be solved, > and that the > >>> approach taken in the connected-identity draft is the best > >>> > >> that can be > >> > >>> achieved. > >>> > >>> If and when there is consensus on a response identity > >>> > >> solution, then > >> > >>> we could consider whether it would be appropriate to > merge the two, > >>> but that is not the case at present. > >>> > >>> John > >>> > >>> > >>>> -----Original Message----- > >>>> From: Rocky Wang [mailto:rocky.wang@huawei.com] > >>>> Sent: 21 March 2006 19:50 > >>>> To: sip@ietf.org > >>>> Subject: [Sip] draft-cao-sip-response-identity-00 and > >>>> draft-elwell-sip-connected-identity-01 > >>>> > >>>> > >>>> Both of draft-cao-sip-response-identity-00 and > >>>> draft-elwell-sip-connected-identity-01 have been disscussed > >>>> > >>> in today's > >>> > >>>> SIP session. I found they two can be merged into one. > >>>> The first one is a common requirement to return back the > identity > >>>> identifier. It can be used in both successful responses, > >>>> > >>> but also in > >>> > >>>> provisiional, redirect and failure responses, but the 2nd > >>>> > >>> one is just > >>> > >>>> used for 18X and 2XX response for INVITE (maybe also some > >>>> > >>> other type > >>> > >>>> requests). > >>>> As I considered, the 2nd one is just a sub-set case of the > >>>> > >>> first one. > >>> > >>>> Can merge the 2nd one into the 1st one? Or merge the > >>>> > >> requirement of > >> > >>>> the 1st into the last. > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use > >>>> sip-implementors@cs.columbia.edu for questions on > current sip Use > >>>> sipping@ietf.org for new developments on the application of sip > >>>> > >>>> > >>> > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 26 00:29:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNNmY-0001pP-9S; Sun, 26 Mar 2006 00:27:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNNmW-0001iR-It for sip@ietf.org; Sun, 26 Mar 2006 00:27:16 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNNmV-00032Z-2i for sip@ietf.org; Sun, 26 Mar 2006 00:27:16 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FNNmR-0000bd-Ri; Sun, 26 Mar 2006 08:27:11 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17446.9775.759042.722531@harjus.tutpro.com> Date: Sun, 26 Mar 2006 08:27:11 +0300 To: "Jeroen van Bemmel" Subject: Re: [Sip] How to indicate during proxy discovery that a proxy supports"outbound" In-Reply-To: <002201c65056$80ac1a90$31713b51@BEMBUSTER> References: <17443.34205.560550.825661@harjus.tutpro.com> <500994B4-BB9F-4075-B95A-E7505B51658C@softarmor.com> <17444.5022.559809.34934@rautu.tutpro.com> <70E5D965-7AF7-4FD7-B6F6-3AB13AF4CA28@softarmor.com> <4425B635.5070107@softarmor.com> <002201c65056$80ac1a90$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, 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: > Could you explain why it is needed that the UA knows whether the proxy > supports outbound before sending its REGISTER request? > > With 'lr' this is clear: the UA must formulate the request differently (i.e. > request URI / Route swap). But when a UA sends a REGISTER with reg-id etc, > it seems that the worst thing that could happen is that the response does > not contain 'Supported: outbound' (but otherwise succeeds). if wg meeting decided that there is only one choice for keepalive protocol (stun), then ";keepalive=xxx" tag is not needed anymore and ";lr" could be default. if so, the default behavior could be that SIP UA makes SRV query and sends REGISTER request to the resulting proxies. if, as you say, REGISTER reply contains "Supported: outbound", then SIP UA knows that the proxies implement outbound I-D and it starts to behave as specified in outbound-id. -- 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 Sun Mar 26 00:56:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNOCj-0000cI-Ai; Sun, 26 Mar 2006 00:54:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNOCh-0000cD-N8 for sip@ietf.org; Sun, 26 Mar 2006 00:54:19 -0500 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 1FNOCf-0003Tr-Al for sip@ietf.org; Sun, 26 Mar 2006 00:54:19 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id AC860830; Sun, 26 Mar 2006 00:54:14 -0500 From: "Hadriel Kaplan" To: "'Juha Heinanen'" , "'Jeroen van Bemmel'" Subject: RE: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Sun, 26 Mar 2006 00:54:12 -0500 Message-ID: <000001c65099$b5b36890$6501a8c0@acmepacket.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: <17446.9775.759042.722531@harjus.tutpro.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcZQli74OHUOhKJNRySR0YbiYN5uUgAAglDQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sip@ietf.org, '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 Actually I don't think the UA knows the proxies support it - only that the Registrar does (since the proxies don't insert in supported, nor delete from it if they don't). There is a way around that - insert a require-proxy and if it's rejected with a 420 then you know. I'm with you that more UA configuration is bad. The second problem is they left the TCP keepalive mechanism in, leaving the door open for a UA which can't do stun in the same port, to talk to a sip-outbound server using the rest of the sip-outbound mechanisms. (I think) -hadriel > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Sunday, March 26, 2006 12:27 AM > To: Jeroen van Bemmel > Cc: sip@ietf.org; Dean Willis > Subject: Re: [Sip] How to indicate during proxy discovery that a > proxysupports"outbound" > > Jeroen van Bemmel writes: > > > Could you explain why it is needed that the UA knows whether the proxy > > supports outbound before sending its REGISTER request? > > > > With 'lr' this is clear: the UA must formulate the request differently > (i.e. > > request URI / Route swap). But when a UA sends a REGISTER with reg-id > etc, > > it seems that the worst thing that could happen is that the response > does > > not contain 'Supported: outbound' (but otherwise succeeds). > > if wg meeting decided that there is only one choice for keepalive > protocol (stun), then ";keepalive=xxx" tag is not needed anymore and > ";lr" could be default. > > if so, the default behavior could be that SIP UA makes SRV query and > sends REGISTER request to the resulting proxies. if, as you say, > REGISTER reply contains "Supported: outbound", then SIP UA knows that > the proxies implement outbound I-D and it starts to behave as specified > in outbound-id. > > -- 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 Sun Mar 26 06:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNTBq-00013D-KN; Sun, 26 Mar 2006 06:13:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNTBq-000138-31 for sip@ietf.org; Sun, 26 Mar 2006 06:13:46 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNTBo-0003pT-NG for sip@ietf.org; Sun, 26 Mar 2006 06:13:46 -0500 Received: (qmail 28958 invoked by uid 0); 26 Mar 2006 11:13:42 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Mar 2006 11:13:42 -0000 Message-ID: <000a01c650c6$53f6aea0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Hadriel Kaplan" , "'Juha Heinanen'" References: <000001c65099$b5b36890$6501a8c0@acmepacket.com> Subject: Re: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Sun, 26 Mar 2006 13:13:36 +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.2670 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, '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 > Actually I don't think the UA knows the proxies support it - only that the > Registrar does (since the proxies don't insert in supported, nor delete > from > it if they don't). > > There is a way around that - insert a require-proxy and if it's rejected > with a 420 then you know. Right, I thought about that too. Perhaps the edge proxy should add a flag to its Path header indicating that it supports outbound. The Proxy-Require approach you mention above would introduce another round trip, which is best avoided So in summary, the mechanism I would propose at the UAC for detection of outbound support: don't add 'keepalive=xxx' to the configured outbound proxy URI, instead first check for Path headers containing a TBD flag (say "outbound"). If there are no Path headers, check for Supported: outbound If there is a need to indicate support for a specific keepalive mechanism (i.e. there are multiple choices), the Path approach can easily be extended. 'Supported' allows no parameters, so one could either define a specific option tag for each keepalive mechanism, or do it in some other way 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 Sun Mar 26 11:26:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY2x-0002Tr-Fz; Sun, 26 Mar 2006 11:24:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY2w-0002Tm-6T for sip@ietf.org; Sun, 26 Mar 2006 11:24:54 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNY2u-0006Sk-W5 for sip@ietf.org; Sun, 26 Mar 2006 11:24:54 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2QGOpw4017140 for ; Sun, 26 Mar 2006 10:24:51 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 26 Mar 2006 17:24:51 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0127491C4@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Sun, 26 Mar 2006 17:24:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Sip] draft-elwell-sip-connected-identity-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 (As chair) At the face-to-face meeting at IETF 65 we agreed that http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.txt formed the basis of part of our charter milestone to provide "Mechanism for Response Identity to IESG (PS). This mail is to confirm that decision using the list. If you have issues with this decision, please respond to this mail. Note: Please keep responses to this thread entirely separate to the thread on draft-cao-sip-response-identity regards Keith Keith Drage drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 26 11:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY37-0002hL-Sj; Sun, 26 Mar 2006 11:25:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY36-0002cz-3S for sip@ietf.org; Sun, 26 Mar 2006 11:25:04 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNY35-0006T3-St for sip@ietf.org; Sun, 26 Mar 2006 11:25:04 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2QGP24R017472 for ; Sun, 26 Mar 2006 10:25:03 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 26 Mar 2006 17:25:02 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0127491CB@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Sun, 26 Mar 2006 17:25:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Future of draft-schwartz-sip-routing-management X-BeenThere: sip@ietf.org X-Mailman-Version: 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 chair) At the SIP working group face-to-face meeting at IETF#65, we discussed: http://www.ietf.org/internet-drafts/draft-schwartz-sip-routing-managment-00.txt It was clear that this needed more discussion of the problem rather than discussion of the solution, and it was suggested that therefore the SIPPING group would be a better home at the moment for this work. The SIP chairs and SIPPING chairs have consulted (this is a word for a quick email exchange) and agree that this work should move to SIPPING. Therefore please direct any further discussion of this draft to the SIPPING list. Note that this document remains an author draft, and this move implies no decision (yet) to progress this draft on behalf of SIPPING. regards Keith Keith Drage drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 26 11:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY38-0002hu-JU; Sun, 26 Mar 2006 11:25:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY36-0002d0-3a for sip@ietf.org; Sun, 26 Mar 2006 11:25:04 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNY35-0006T2-S3 for sip@ietf.org; Sun, 26 Mar 2006 11:25:04 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2QGP27b017469 for ; Sun, 26 Mar 2006 10:25:02 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 26 Mar 2006 17:25:02 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0127491CA@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Sun, 26 Mar 2006 17:24:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] draft-niemi-sip-subnot-etags-00.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 chair) http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-00.txt makes a proposal for: " The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of events related to SIP systems. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures have a serious deficiency in that they do not allow state to persist over a subscription refresh, or between two consecutive polls. Another related but different problem relates to the relative intolerance of the framework to interferences in networking connectivity of subscribers in long- lasting subscriptions. This document explains the problems in more detail and discusses possible solutions." This draft was discussed at the face-to-face meeting at IETF #65 but without conclusion. We seek views on whether the SIP WG should adopt a draft in this area as a charter item, and if so, what scope that charter item should have. regards Keith Keith Drage drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 26 11:26:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY30-0002VW-Ub; Sun, 26 Mar 2006 11:24:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY2z-0002U3-0h for sip@ietf.org; Sun, 26 Mar 2006 11:24:57 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNY2y-0006Sq-QT for sip@ietf.org; Sun, 26 Mar 2006 11:24:57 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2QGOsO2017223 for ; Sun, 26 Mar 2006 10:24:55 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 26 Mar 2006 17:24:54 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0127491C6@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Sun, 26 Mar 2006 17:24:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] draft-cao-sip-response-identity-00.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 chair) At the face-to-face meeting at IETF #65 we discussed: http://www.ietf.org/internet-drafts/draft-cao-sip-response-identity-00.txt as a proposal for part of the solution to meeting the SIP milestone "Mechanism for Response Identity to IESG (PS) A separate thread identifies another draft that forms part of this solution. The face-to-face meeting reached no conclusion about whether this draft forms the basis for completing that milestone, or whether the problem cannot be resolved at all (or indeed that there is no support for a solution in this area) and therefore we should modify the existing milestone to remove response identity and leave only connected identity. We would welcome proposals and comments to the list to resolve this issue one way or the other. regards Keith Keith Drage drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 26 11:26:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY34-0002Z6-4l; Sun, 26 Mar 2006 11:25:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY33-0002Ye-1W for sip@ietf.org; Sun, 26 Mar 2006 11:25:01 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNY32-0006Sv-QJ for sip@ietf.org; Sun, 26 Mar 2006 11:25:01 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2QGOxaY017365 for ; Sun, 26 Mar 2006 10:24:59 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 26 Mar 2006 17:24:59 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0127491C8@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Sun, 26 Mar 2006 17:24:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] draft-rosenberg-sip-hitchhikers-guide-00.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 chair) At the face-to-face meeting at IETF#65 we agreed to adopt http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchhikers-guide-00.txt as part of the basis for our milestone on producing a roadmap. This message is to seek list confirmation of that decision. If you have issues with adopting http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchhikers-guide-00.txt as the baseline for this work, then please communicate this with the list. regard Keith Keith Drage drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 26 11:26:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY2z-0002Ua-6l; Sun, 26 Mar 2006 11:24:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNY2y-0002Tx-0e for sip@ietf.org; Sun, 26 Mar 2006 11:24:56 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNY2x-0006Sn-PY for sip@ietf.org; Sun, 26 Mar 2006 11:24:56 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2QGOsO1017223 for ; Sun, 26 Mar 2006 10:24:54 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 26 Mar 2006 17:24:54 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Sun, 26 Mar 2006 17:24:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] draft-tschofenig-sip-saml-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 (As chair) At the face-to-face meeting at IETF#65, we discussed http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt as a possible solution to the current milestone on "Using SAML for SIP (PS)". We are seeking a list hum on whether this draft should be adopted as baseline for this draft, or whether we should seek some other baseline input. regards Keith Keith Drage drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 26 12:49:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNZLA-0003wI-MB; Sun, 26 Mar 2006 12:47:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNZL9-0003wD-4j for sip@ietf.org; Sun, 26 Mar 2006 12:47:47 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNZL7-0000aX-RK for sip@ietf.org; Sun, 26 Mar 2006 12:47:47 -0500 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 <0IWQ00GPSXAADA@usaga01-in.huawei.com> for sip@ietf.org; Sun, 26 Mar 2006 09:44:35 -0800 (PST) Received: from huawei.com ([172.17.1.102]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWQ008WEXA9Q0@usaga01-in.huawei.com> for sip@ietf.org; Sun, 26 Mar 2006 09:44:34 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [216.74.250.138]) by szxmc02-in.huawei.com (mshttpd); Sun, 26 Mar 2006 11:47:50 -0600 Date: Sun, 26 Mar 2006 11:47:50 -0600 From: xupeili 18916 Subject: Re: [Sip] draft-niemi-sip-subnot-etags-00.txt To: "Drage, Keith (Keith)" Message-id: <14c881714c6c1a.14c6c1a14c8817@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) 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 Hi All, If we are to consider optimization of notification, I suggest we consider more than optimization of the notification body, for example, the batch subscription refreshment mentioned in draft-wang-sip-brs-00.txt to get a more through solution. regards Peili Xu ----- Original Message ----- From: "Drage, Keith (Keith)" Date: Sunday, March 26, 2006 10:24 am Subject: [Sip] draft-niemi-sip-subnot-etags-00.txt > (As chair) > > http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags- > 00.txt makes a proposal for: > > " The Session Initiation Protocol (SIP) events framework enables > receiving asynchronous notification of events related to SIP > systems. This framework defines the procedures for creating, > refreshing and > terminating subscriptions, as well as fetching and periodic polling > of resource state. These procedures have a serious deficiency in > that they do not allow state to persist over a subscription > refresh, or between two consecutive polls. Another related but > different problem relates to the relative intolerance of the > framework to > interferences in networking connectivity of subscribers in long- > lasting subscriptions. This document explains the problems in more > detail and discusses possible solutions." > > This draft was discussed at the face-to-face meeting at IETF #65 > but without conclusion. > > We seek views on whether the SIP WG should adopt a draft in this > area as a charter item, and if so, what scope that charter item > should have. > > regards > > Keith > > Keith Drage > drage@lucent.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 26 14:02:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNaTc-0003fL-Vx; Sun, 26 Mar 2006 14:00:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNaTb-0003fG-Ti for sip@ietf.org; Sun, 26 Mar 2006 14:00:35 -0500 Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNaTa-00040J-Mn for sip@ietf.org; Sun, 26 Mar 2006 14:00:35 -0500 Received: from user-2ivf973.dsl.mindspring.com ([165.247.164.227] helo=JMHLap3.stevecrocker.com) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FNaTZ-00039v-00 for sip@ietf.org; Sun, 26 Mar 2006 14:00:34 -0500 Message-Id: <7.0.1.0.0.20060326140008.0328c110@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 26 Mar 2006 14:00:33 -0500 To: sip@ietf.org From: "Joel M. Halpern" Subject: Re: [Sip] draft-tschofenig-sip-saml-05.txt In-Reply-To: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk .lucent.com> References: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 seems like a good starting point to me. Joel At 11:24 AM 3/26/2006, Drage, Keith (Keith) wrote: >(As chair) > >At the face-to-face meeting at IETF#65, we discussed >http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt >as a possible solution to the current milestone on "Using SAML for SIP (PS)". > >We are seeking a list hum on whether this draft should be adopted as >baseline for this draft, or whether we should seek some other baseline input. > >regards > >Keith > >Keith Drage >drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 26 14:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNbE5-0005Wr-BD; Sun, 26 Mar 2006 14:48:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNbE3-0005Wm-KT for sip@ietf.org; Sun, 26 Mar 2006 14:48:35 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNbE2-0005aC-Cm for sip@ietf.org; Sun, 26 Mar 2006 14:48:35 -0500 Received: from s010600095b9792b5.vc.shawcable.net ([70.79.6.118] helo=[192.168.0.101]) by dns.aliantmedia.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FNbE0-0004pj-Ol; Sun, 26 Mar 2006 13:48:32 -0600 Message-ID: <4426F00B.8040802@ntt-at.com> Date: Sun, 26 Mar 2006 11:48:27 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] draft-tschofenig-sip-saml-05.txt References: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org 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 As I commented before, I think the authors have done a great job at simplifying the SAML-SIP spec. I agree with the direction it's taking, although we might see some other profiles needed in the future to accommodate use-cases that the current spec might not be able to cover(I think the current spec covers majority of use-cases that people are considering). Anyhow, here is my hum to support the work and its direction that it's taking. Regards Shida Drage, Keith (Keith) wrote: > (As chair) > > At the face-to-face meeting at IETF#65, we discussed http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt as a possible solution to the current milestone on "Using SAML for SIP (PS)". > > We are seeking a list hum on whether this draft should be adopted as baseline for this draft, or whether we should seek some other baseline input. > > regards > > Keith > > Keith Drage > drage@lucent.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 26 17:16:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNdVa-00014Q-Bd; Sun, 26 Mar 2006 17:14:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNdVY-00014D-BR for sip@ietf.org; Sun, 26 Mar 2006 17:14:48 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNdVY-00031I-0Z for sip@ietf.org; Sun, 26 Mar 2006 17:14:48 -0500 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2QMFICQ025978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Mar 2006 16:15:19 -0600 Message-ID: <44271255.1030705@softarmor.com> Date: Sun, 26 Mar 2006 16:14:45 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] How to indicate during proxy discovery that a proxy supports"outbound" References: <17443.34205.560550.825661@harjus.tutpro.com> <500994B4-BB9F-4075-B95A-E7505B51658C@softarmor.com> <17444.5022.559809.34934@rautu.tutpro.com><70E5D965-7AF7-4FD7-B6F6-3AB13AF4CA28@softarmor.com> <4425B635.5070107@softarmor.com> <002201c65056$80ac1a90$31713b51@BEMBUSTER> In-Reply-To: <002201c65056$80ac1a90$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org, 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 Jeroen van Bemmel wrote: > Dean, > > Could you explain why it is needed that the UA knows whether the proxy > supports outbound before sending its REGISTER request? > > With 'lr' this is clear: the UA must formulate the request differently > (i.e. request URI / Route swap). But when a UA sends a REGISTER with > reg-id etc, it seems that the worst thing that could happen is that the > response does not contain 'Supported: outbound' (but otherwise succeeds). Good question. Critical question for establishing a requirement, so let's see if we can answer it. There are two ways we can establish compatibility with an extensions: 1) By foreknowledge 2) By experimentation -- try it and see if it works. Both have limitations: In the case of #1, we might have incorrect knowledge. So we'll probably end up testing anyhow . . . In the case of #2, the experiment might cause a meltdown. So the "probe for discovery" must be made completely safe. Also, we can eventually end up with so many wierd hooks and idiosyncratic implementations that we end up doing a BUNCH of probing before we do any real communicating. And it's possible for the conditions to deteriorate so much that probes for two different possible conditions are mutually exclusive -- if one condition applies, the probe for another will cause a meltdown. So what happens if we start STUN-probing a proxy on its SIP port and it doesn't support STUN? My guess is, it's random. So, we should "probe for discover" only when we either expect it tow work (via foreknowledge) or we know that the test is completely safe. The -03 text says: 4.4.1 Keep Alive with STUN User Agents that form flows MUST check if the configured URI they are connecting to has a 'keepalive' URI parameter (defined in Section 10) with the value of 'stun'. If the parameter is present, the UA needs to periodically perform keep alive checks by sending a STUN [7] Binding Requests over the flow. So there's a presumption that it is IMPORTANT that we know that a proxy supports keepalive using STUN. Note that we don't blindly probe, because the probe might well be destructive to an unsupporting proxy. I had a very interesting talk last week with Yngve Petterson, one of the developers of the "Opera" browswer. He does a lot of work with SSL/TLS, and cautioned me that we need to think very carefully about "forward compatibility" design in SIP. TLS didn't, so they end up having this complex negotiation process where they try things and hope it works. Sometimes it takes several from-scratch connection start attempts before a "magic combination that works" is discovered. One approach to "forward compatibility" design is to make sure that we can use both foreknowledge and experimentation -- the "trust but verify" model. We also have "foreknowledge" -03: 4.2 Initial Registrations UAs are configured with one or more SIP URIs representing the default outbound-proxy-set. The specification assumes the set is determined via configuration but future specifications may define other mechanisms such as using DNS to discover this set. While it's easy to decide whether a configured registrar URI has a keepalive parameter, what happens to proxies we select based on something besides direct configuration? Specifically, 1) Can the DHCP option for default proxy present the keepalive parameter? I haven't looked yet . . . 2) Can a UA using the mechanismn suggested by Juha, which I read as "look in DNS for an SRV record supporting the domain of the AOR" present the keepalive parameter? If not, how do we get around the limitation? -- 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 Sun Mar 26 20:09:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNgCp-0002Gi-Pb; Sun, 26 Mar 2006 20:07:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNgCo-0002D2-9u for sip@ietf.org; Sun, 26 Mar 2006 20:07:38 -0500 Received: from ylpvm01-ext.prodigy.net ([207.115.57.32] helo=ylpvm01.prodigy.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNgCn-0002Iy-1M for sip@ietf.org; Sun, 26 Mar 2006 20:07:38 -0500 Received: from pimout2-ext.prodigy.net (pimout2-int.prodigy.net [207.115.4.217]) by ylpvm01.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k2R17Yag029019 for ; Sun, 26 Mar 2006 20:07:34 -0500 X-ORBL: [71.141.102.115] Received: from toshibauser (adsl-71-141-102-115.dsl.snfc21.pacbell.net [71.141.102.115]) by pimout2-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with SMTP id k2R17XXE074642; Sun, 26 Mar 2006 20:07:35 -0500 From: "Erick Sasaki" To: "Drage, Keith \(Keith\)" , Subject: RE: [Sip] draft-tschofenig-sip-saml-05.txt Date: Sun, 26 Mar 2006 17:07:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: 1.8 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: esasaki@shui-usjapan.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think it looks good as a base document and should continue forward, so my hum for support. Erick -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Sunday, March 26, 2006 8:25 AM To: sip@ietf.org Subject: [Sip] draft-tschofenig-sip-saml-05.txt (As chair) At the face-to-face meeting at IETF#65, we discussed http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt as a possible solution to the current milestone on "Using SAML for SIP (PS)". We are seeking a list hum on whether this draft should be adopted as baseline for this draft, or whether we should seek some other baseline input. regards Keith Keith Drage drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 26 21:17:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNhGs-0004CS-5Y; Sun, 26 Mar 2006 21:15:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNhGq-0004CN-G8 for sip@ietf.org; Sun, 26 Mar 2006 21:15:52 -0500 Received: from [219.141.250.5] (helo=mail) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNhGo-0004ES-ST for sip@ietf.org; Sun, 26 Mar 2006 21:15:52 -0500 Received: from swtangxi (sw-tangxi.cecwireless.com.cn [10.2.4.97]) by mail.cecwireless.com.cn (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTPA id <0IWR003WNKOZF4@mail.cecwireless.com.cn> for sip@ietf.org; Mon, 27 Mar 2006 10:10:18 +0800 (CST) Date: Mon, 27 Mar 2006 10:10:49 +0800 From: "xi.tang" To: sip@ietf.org Message-id: <000c01c65143$ab7b96e0$6104020a@cecwireless.com.cn> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZRQ6o+h2YC57gESMuaqTAIKVBuKQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sip] is there any rfc for transfering file by 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: , Content-Type: multipart/mixed; boundary="===============0528095560==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0528095560== Content-type: multipart/alternative; boundary="Boundary_(ID_vhzM08vcMP73riWJb2nUdA)" This is a multi-part message in MIME format. --Boundary_(ID_vhzM08vcMP73riWJb2nUdA) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT is there any sdp rfc for transfering file by sip? --Boundary_(ID_vhzM08vcMP73riWJb2nUdA) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT is there any sdp rfc for transfering file by sip?
 
--Boundary_(ID_vhzM08vcMP73riWJb2nUdA)-- --===============0528095560== 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 --===============0528095560==-- From sip-bounces@ietf.org Sun Mar 26 21:58:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNhuc-0000J4-0u; Sun, 26 Mar 2006 21:56:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNhub-0000Iz-8H for sip@ietf.org; Sun, 26 Mar 2006 21:56:57 -0500 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 1FNhuZ-0005cw-VX for sip@ietf.org; Sun, 26 Mar 2006 21:56:57 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A46B0490; Sun, 26 Mar 2006 21:56:43 -0500 From: "Hadriel Kaplan" To: "'Dean Willis'" , "'Jeroen van Bemmel'" Subject: RE: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Sun, 26 Mar 2006 21:56:47 -0500 Message-ID: <004d01c6514a$17e3c270$6501a8c0@acmepacket.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: <44271255.1030705@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcZRIuBFXkefPLfkSoeIglpl9i722AABAPWQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip@ietf.org, '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 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Sunday, March 26, 2006 5:15 PM > To: Jeroen van Bemmel > Cc: sip@ietf.org; Juha Heinanen > Subject: Re: [Sip] How to indicate during proxy discovery that a > proxysupports"outbound" > There are two ways we can establish compatibility with an extensions: > > 1) By foreknowledge > 2) By experimentation -- try it and see if it works. There is a 3rd: explicit, signaled negotiation. I don't think anyone is asking for a stun probe to check if the server supports it. (at least I haven't interpreted that) I agree that would be a bad way to go. But why would that be needed - isn't stun sent *after* registration? There are mechanisms to check sip-outbound compliance in this, right? And since you mandate the server support stun, then if it indicates to the UA outbound compliance, you're done. The only rub is the current draft doesn't take into account a proxy indicating outbound compliance. So you can either mandate explicitly verifying through proxy-require (and require: while you're at it), which would take one extra round-trip only if it fails. Or make the UA add something in the Register that a sip-outbound compliant proxy would remove, or whatever. Then mandate stun can't be sent until registration is complete and the next-hop indicated support for outbound. If you're worried about a "proxy" being in the path that isn't "visible", then it may not be "visible" to the person doing configuration either. Or configuration screw-ups may be problems too. As so often argued against SBCs in this forum: I'm not sure we should be worried about non-compliant phantom boxes. We just have to make sure it won't break compliant ones. The only real solution otherwise would be to make this a new default port and SRV record service type for "SIP-O" and "SIPS-O", or some such, since what you are implying is the outbound mechanism is fundamentally different than SIP, I think. But my view is that would be worse than just negotiating it using SIP. > The -03 text says: > > 4.4.1 Keep Alive with STUN [snipped] I should note that as far as I can tell, the draft says a UA with the keepalive=stun URI MUST use stun, but does not mandate that for a URI without it the UA MUST NOT use stun. (no?) So I think we are allowing a UA to send STUN without foreknowledge the next-hop can handle it. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 26 22:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNiAw-0002Co-Rg; Sun, 26 Mar 2006 22:13:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNiAu-0002Bj-Q7 for sip@ietf.org; Sun, 26 Mar 2006 22:13:48 -0500 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 1FNiAu-0006s0-IJ for sip@ietf.org; Sun, 26 Mar 2006 22:13:48 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A8680978; Sun, 26 Mar 2006 22:13:44 -0500 From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" , "'Juha Heinanen'" Subject: RE: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Sun, 26 Mar 2006 22:13:50 -0500 Message-ID: <005101c6514c$787b51f0$6501a8c0@acmepacket.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: <000a01c650c6$53f6aea0$31713b51@BEMBUSTER> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcZQxln6g8OwyRclRRyfyiCjjjGLiQAhLLew X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org, '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 > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Sunday, March 26, 2006 6:14 AM > To: Hadriel Kaplan; 'Juha Heinanen' > Cc: sip@ietf.org; 'Dean Willis' > Subject: Re: [Sip] How to indicate during proxy discovery that a > proxysupports"outbound" > > So in summary, the mechanism I would propose at the UAC for detection of > outbound support: > don't add 'keepalive=xxx' to the configured outbound proxy URI, instead > first check for Path headers containing a TBD flag (say "outbound"). If > there are no Path headers, check for Supported: outbound But there are 3261 compliant proxies out there that don't support Path. So you will not know if the register went through one of those and hit an outbound registrar, vs. there was no proxy. I think a proxy-require is the only safe bet (and it would work across multiple proxies). It only means an extra round-trip if it fails, and the truth is you do require the proxy to support something, so why not use the header defined for that? > 'Supported' allows no parameters, so one could either define a specific > option tag for each keepalive mechanism, or do it in some other way I think once the UA figures out the next-hop can do outbound, it knows it can do stun, because servers are mandated to support stun if they support outbound. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 26 22:16:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNiB4-0002Sp-Nk; Sun, 26 Mar 2006 22:13:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNiB2-0002Q4-Rs for sip@ietf.org; Sun, 26 Mar 2006 22:13:56 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNiAz-0006s5-Ll for sip@ietf.org; Sun, 26 Mar 2006 22:13:56 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 5521E6C01C for ; Sun, 26 Mar 2006 22:13:53 -0500 (EST) Subject: Re: [Sip] is there any rfc for transfering file by sip? From: "Dale R. Worley" To: Sip In-Reply-To: <000c01c65143$ab7b96e0$6104020a@cecwireless.com.cn> References: <000c01c65143$ab7b96e0$6104020a@cecwireless.com.cn> Content-Type: text/plain Date: Sun, 26 Mar 2006 22:13:53 -0500 Message-Id: <1143429233.21390.5.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mon, 2006-03-27 at 10:10 +0800, xi.tang wrote: > is there any sdp rfc for transfering file by sip? You might want to look at draft-isomaki-sipping-file-transfer-00. 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 Mar 27 02:29:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNm7g-0001le-HZ; Mon, 27 Mar 2006 02:26:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNm7a-0001iI-7n for sip@ietf.org; Mon, 27 Mar 2006 02:26:38 -0500 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNm7Y-0006zZ-Jl for sip@ietf.org; Mon, 27 Mar 2006 02:26:38 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 779DA74100; Mon, 27 Mar 2006 09:26:35 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12368-01-15; Mon, 27 Mar 2006 09:26:35 +0200 (CEST) Received: from dhcp-wavelan-v-37.publik.su.se (dhcp-wavelan-v-37.publik.su.se [193.10.145.37]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 76C8F7407D; Mon, 27 Mar 2006 09:26:22 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Mon, 27 Mar 2006 09:26:04 +0200 User-Agent: KMail/1.9.1 References: <005101c6514c$787b51f0$6501a8c0@acmepacket.com> In-Reply-To: <005101c6514c$787b51f0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603270926.04600.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.665 tagged_above=-99 required=7 tests=[BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: '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 On Monday 27 March 2006 05:13, Hadriel Kaplan wrote: ... > > So in summary, the mechanism I would propose at the UAC for > > detection of outbound support: > > don't add 'keepalive=xxx' to the configured outbound proxy URI, > > instead first check for Path headers containing a TBD flag (say > > "outbound"). If there are no Path headers, check for Supported: > > outbound > > But there are 3261 compliant proxies out there that don't support > Path. So you will not know if the register went through one of those > and hit an outbound registrar, vs. there was no proxy. I think a > proxy-require is the only safe bet (and it would work across multiple > proxies). It only means an extra round-trip if it fails, and the > truth is you do require the proxy to support something, so why not > use the header defined for that? > > > 'Supported' allows no parameters, so one could either define a > > specific option tag for each keepalive mechanism, or do it in some > > other way > > I think once the UA figures out the next-hop can do outbound, it > knows it can do stun, because servers are mandated to support stun if > they support outbound. Proxy-Require: outbound won't work when the next-hop from the UA supports outbound, but other proxies on the way to the home proxy (registrar) does not. Consider the following : UA --- | --- P1 --- P2 --- Registrar NAT P1 supports Outbound, and is there to help the UA traverse the NAT. P2 is the proxy indicated in DNS for the UA's "home domain", but it proxies all REGISTER requests to Registrar. P2 does not support Outbound, and should not be required to do so. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 27 04:40:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNoAy-0000BP-Iz; Mon, 27 Mar 2006 04:38:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNoAx-0000AR-BZ for sip@ietf.org; Mon, 27 Mar 2006 04:38:15 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNn35-0001XZ-6B for sip@ietf.org; Mon, 27 Mar 2006 03:26:03 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FNmr4-0006HC-9G for sip@ietf.org; Mon, 27 Mar 2006 03:13:41 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B3ED74F0002; Mon, 27 Mar 2006 10:13:36 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 10:13:36 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 10:13:35 +0200 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 Subject: RE: [Sip] draft-ietf-sip-outbound Date: Mon, 27 Mar 2006 10:13:34 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1BCB@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZPtSfjf3cpCg4FRYqLQ/oo0vWzSABwIgyA From: "Christer Holmberg \(JO/LMF\)" To: , "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 27 Mar 2006 08:13:35.0331 (UTC) FILETIME=[5822E330:01C65176] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) 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 Hi, I was not at the face-to-face meeting, but from the mail discussion I haven't seen a sign of consensus. I think we should get the pros and cons of each solution documented, and go from there. Maybe that study was done and discussed at the face-to-face meeting, but then I would ask Keith (or someone else) to share that study with the rest of us, so we can see what the facts the consensus was made based on. I am not saying that PING would be the best solution, but I do agree with Frank that one solution does not necessarily preclude others. Regards, Christer =20 -----Original Message----- From: Frank W. Miller [mailto:fwmiller@cornfed.com]=20 Sent: 25. maaliskuuta 2006 4:37 To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-outbound On Sat, 2006-03-25 at 00:51 +0000, Drage, Keith (Keith) wrote: > (as chair) >=20 > As a result of the face-to-face meeting held at IETF #65, we agreed in the room on the keepalive mechanism: >=20 > - OS TCP KeepAlive should be used if the client supports it. > - Need something more because OS TCP KeepAlive is not supported in every client OS. > - Consensus to use STUN for UDP > - Consensus to use STUN for TCP, with use of OS TCP keep alive above. >=20 > 2) Working group: Any dissent to the agreements listed above or do we have rough consensus to proceed according to the agreements made in the meeting >=20 I have dissent on the use of STUN exclusively for keepalive. I believe that a SIP based mechanism such as the PING draft I proposed is a better solution. The essence of my objection is that I think it is a mistake to have both STUN and SIP residing on the same port. I think this makes little sense for three reasons: 1) its architecturally in conflict with the way most other protocols are defined, i.e. each protocol generally lives on its own port, 2) it unnecessarily complicates implementations when there is a very simple way to do it within SIP, and most importantly 3) it is going to make it very difficult to use STUN for the same task with other protocols that will need keepalives. Also, I don't believe that the performance issues that have been put forth are substantive enough to cause the architectural violations that result from using STUN this way. If the group is dead set on using STUN this way, the SIP way should at least be acknowledged by 1) including a ;keepalive=3Dping tag for the = URI in the outbound draft and 2) allowing the PING draft to become an ietf draft. These actions place very little additional burden on implementors and will allow the "market" to decide which is the right one to be used operationally. Dissent registered. 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 27 07:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNqXp-00060f-Ji; Mon, 27 Mar 2006 07:10:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNqXo-00060a-4q for sip@ietf.org; Mon, 27 Mar 2006 07:10:00 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNqXm-0003WF-IW for sip@ietf.org; Mon, 27 Mar 2006 07:10:00 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2RC9tAs011210; Mon, 27 Mar 2006 15:09:57 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 15:09:56 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 15:09:57 +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] How to indicate during proxy discovery that aproxysupports"outbound" Date: Mon, 27 Mar 2006 15:09:55 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02201AED@esebe103.NOE.Nokia.com> In-Reply-To: <200603270926.04600.ft@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Thread-Index: AcZRcE5CQ1PkpbaoTOKVfarb5yuTxAAIQENg From: To: , X-OriginalArrivalTime: 27 Mar 2006 12:09:57.0092 (UTC) FILETIME=[5D1FE240:01C65197] X-Spam-Score: 0.2 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: jh@tutpro.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, Here is my short summary about the proposals given, problems related to them and my proposal as the way forward: >While it's easy to decide whether a configured registrar URI has a=20 >keepalive parameter, what happens to proxies we select based on=20 >something besides direct configuration? > >Ok, I think we've boiled this down to a new requirement: >for the "outbound" technique to work, we MUST have a means of =20 >discovering whether a proxy supports the extensions of outbound. I fully agree with this requirement, since there are use cases (e.g. with DHCP SIP proxy discovery) where outbound support can simply not be found from the UA configuration. A. Negotiation with SIP >Supported: I don't think the UA knows the proxies support it -=20 >only that the Registrar does (since the proxies don't insert=20 >in supported, nor delete from it if they don't). >Proxy-Require: outbound won't work when the next-hop from the UA=20 >supports outbound, but other proxies on the way to the home proxy=20 >(registrar) does not. >Path: But there are 3261 compliant proxies out there that don't=20 >support Path. So you will not know if the register went through=20 >one of those and hit an outbound registrar, vs. there was no proxy.=20 B. Using DNS >1) Deducing from the proxy URL that it supports Outbound. This =20 >potentially works with DNS, DHCP, and configured discovery, but might =20 >just be a little too weird with our existing syntax and conventions. >2) Using a different service record in DNS, which works for DNS but =20 >not DHCP or configured use cases, I think. >The only real solution otherwise would be to make this a new default=20 >port and SRV record service type for "SIP-O" and "SIPS-O", or some=20 >such, since what you are implying is the outbound mechanism is=20 >fundamentally different than SIP, I think. I do not think a new default port is needed since you can always indicate the port within SRV records. But apart that I believe this would be the way to go i.e. to define a few new NAPTR service types for Outbound, something like: "SIPS-O+D2T" "SIP-O+D2T" "SIP-O+D2U" Benefits of this solution: - Would enable the UA to specifically select the proxies=20 supporting Outbound, instead of only blindly trying whether=20 any of the resolved proxies would support it - Would tell the UA whether the proxy supports Outbound or not even before starting to communicate the proxy and avoids the extra transactions caused by the proxy rejecting or redirecting the REGISTER request - Would also support the case where domain name of the proxy is discovered by DHCP. As DHCP returns proxy domain names without port or transport, it causes the UA to make a NAPTR query for that domain, according to RFC 3263 - Does not introduce backwards compatibility problems for UAs not supporting Outbound, since those UAs would discard those new NAPTR service types according to RFC 3263 rules - No new SRV records would be needed since those new NAPTR records could be mapped to the very same SRV RRs that would be used for=20 good old "SIPS+D2T" "SIP+D2T" "SIP+D2U" services, if the same proxy could be used with or without Outbound Drawbacks of the solution: - Three new NAPTR service types and records needed for introducing one new type of service - Relies on the UA to implement NAPTR processing (which I think is reasonable as Outbound has a number of new reqs anyway) Further on I would like to propose handling of the primary and backup proxy issue ... >While outbound promotes ways for using multiple connections towards >multiple proxies it does not yet address the problem of discovering >those proxies=20 ... so that if the service resolved is "SIP-O+D2X" then the UA could open a separate connection towards the preferred proxy at each priority level of the SRV records for the service. This would be a change to RFC 3263 procedures, that result connecting to only one single proxy and then exiting the search. Comments, please ? 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 Mar 27 10:02:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtCq-0001Z2-PM; Mon, 27 Mar 2006 10:00:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtCp-0001Yx-0S for sip@ietf.org; Mon, 27 Mar 2006 10:00:31 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtCn-0001gx-MC for sip@ietf.org; Mon, 27 Mar 2006 10:00:30 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2RF0Sp7014752 for ; Mon, 27 Mar 2006 09:00:28 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2RF0R827452; Mon, 27 Mar 2006 09:00:27 -0600 (CST) Message-ID: <4427FE0B.9080300@lucent.com> Date: Mon, 27 Mar 2006 09:00:27 -0600 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] draft-tschofenig-sip-saml-05.txt References: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 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="===============1622449332==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1622449332== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010309010601050905080705" This is a cryptographically signed message in MIME format. --------------ms010309010601050905080705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > (As chair) > > At the face-to-face meeting at IETF#65, we discussed > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt > as a possible solution to the current milestone on "Using SAML for > SIP (PS)". > > We are seeking a list hum on whether this draft should be adopted as > baseline for this draft, or whether we should seek some other > baseline input. I would say yes, this is a good draft. At least for me, it solified some of the thoughts in this area. Out of curiosity, we don't have any other baseline drafts that deal with SIP and SAML do we? This is the only one I am aware of. The spit-saml and saml-cpc drafts could be characterized as profiles of sip-saml... Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms010309010601050905080705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjcxNTAwMjdaMCMGCSqGSIb3DQEJ BDEWBBQFU609jmGvOCM2gWpIld8XJtWfkjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAY0M9U+j7cr7esPU9aFrL6cGMJDpr3kU2MfZdtVzdoeTq23s+MIQa KyXhfmRHgxRYSdovEE3WGy5qtTvAuCnbVxYLFed2j8KjKTprDg3bpTmQa9Ke3fhprMWvKwrR u23v1eiOSFzNMck/v6JpCrxC9dKlG2DakqE3YVuu5/5NjgQAAAAAAAA= --------------ms010309010601050905080705-- --===============1622449332== 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 --===============1622449332==-- From sip-bounces@ietf.org Mon Mar 27 10:43:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtqr-0007nn-48; Mon, 27 Mar 2006 10:41:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtqp-0007nh-6j for sip@ietf.org; Mon, 27 Mar 2006 10:41:51 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtqn-0003nY-Ip for sip@ietf.org; Mon, 27 Mar 2006 10:41:51 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k2RFflhE011699; Mon, 27 Mar 2006 17:41:48 +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 k2RFfljY025164; Mon, 27 Mar 2006 17:41:47 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 17:40: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sip] draft-tschofenig-sip-saml-05.txt Date: Mon, 27 Mar 2006 17:39:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-tschofenig-sip-saml-05.txt Thread-Index: AcZRr4wZCp4C3+mBTOqH4n6J/ZFIjQABMIyw From: "Tschofenig, Hannes" To: "Vijay K. Gurbani" , "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 27 Mar 2006 15:40:50.0808 (UTC) FILETIME=[D353B780:01C651B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Vijay,=20 =20 please find a comment inline: > -----Urspr=FCngliche Nachricht----- > Von: Vijay K. Gurbani [mailto:vkg@lucent.com]=20 > Gesendet: Montag, 27. M=E4rz 2006 09:00 > An: Drage, Keith (Keith) > Cc: sip@ietf.org > Betreff: Re: [Sip] draft-tschofenig-sip-saml-05.txt >=20 > Drage, Keith (Keith) wrote: > > (As chair) > >=20 > > At the face-to-face meeting at IETF#65, we discussed > > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt > > as a possible solution to the current milestone on "Using SAML for > > SIP (PS)". > >=20 > > We are seeking a list hum on whether this draft should be adopted as > > baseline for this draft, or whether we should seek some other > > baseline input. >=20 > I would say yes, this is a good draft. At least for me, it > solified some of the thoughts in this area. >=20 > Out of curiosity, we don't have any other baseline drafts that > deal with SIP and SAML do we?=20 What do you mean by "other baseline drafts"? > This is the only one I am aware > of. The spit-saml and saml-cpc drafts could be characterized > as profiles of sip-saml... Well, it depends what you put into the main document. Regarding the = SAML-CPC work: We plan to align it with the recent version of SIP-SAML = as Shida mentioned during the SIPPING session. This would then require = us only to register a few values for usage with CPC.=20 Ciao Hannes >=20 > Thanks, >=20 > - vijay > --=20 > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Bell Laboratories, Lucent Technologies, Inc. > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >=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 Mar 27 11:03:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuAB-0004BA-2f; Mon, 27 Mar 2006 11:01:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuA9-0004B5-Mg for sip@ietf.org; Mon, 27 Mar 2006 11:01:49 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNuA8-0004UV-CQ for sip@ietf.org; Mon, 27 Mar 2006 11:01:49 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2RG1la3007656; Mon, 27 Mar 2006 10:01:47 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2RG1k826387; Mon, 27 Mar 2006 10:01:46 -0600 (CST) Message-ID: <44280C6A.5000307@lucent.com> Date: Mon, 27 Mar 2006 10:01:46 -0600 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: "Tschofenig, Hannes" Subject: Re: AW: [Sip] draft-tschofenig-sip-saml-05.txt References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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="===============1933381029==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1933381029== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020509030305050502000100" This is a cryptographically signed message in MIME format. --------------ms020509030305050502000100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tschofenig, Hannes wrote: > Hi Vijay, > > please find a comment inline: [...] >> I would say yes, this is a good draft. At least for me, it >> solified some of the thoughts in this area. >> >> Out of curiosity, we don't have any other baseline drafts that deal >> with SIP and SAML do we? > > What do you mean by "other baseline drafts"? Hannes: I was riding off Keith's comment, which was: "We are seeking a list hum on whether this draft should be adopted as baseline for this draft, or whether we should seek some other baseline input." ^^^^^^^^^^^^^^^^^^^^^ So, I wanted to make sure that there was not any other work in the area of a SIP profile for SAML besides sip-saml-05. >> This is the only one I am aware of. The spit-saml and saml-cpc >> drafts could be characterized as profiles of sip-saml... > > Well, it depends what you put into the main document. Regarding the > SAML-CPC work: We plan to align it with the recent version of > SIP-SAML as Shida mentioned during the SIPPING session. This would > then require us only to register a few values for usage with CPC. Ah, ok. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms020509030305050502000100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjcxNjAxNDZaMCMGCSqGSIb3DQEJ BDEWBBRU/IlpfHsxriJsFk5DompNw9n9SzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAM8AeJ/44fXglQPOUR4Bhw7tUeag7BUHiTboOZyVYKLam2gLGoVnT iH07l2w7hkZhODGaF5Z8r6seZS4GtQa6k4NdCCyMdUqsxkoAQvdXbmSQhYAXO45nSRCa/3ee miXSnHwQSQYtssZbkNcmP9Fc0/TNERH7DvGM88uK+MdcszQAAAAAAAA= --------------ms020509030305050502000100-- --===============1933381029== 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 --===============1933381029==-- From sip-bounces@ietf.org Mon Mar 27 11:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuvC-0001z6-4v; Mon, 27 Mar 2006 11:50:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuvA-0001x9-VP for sip@ietf.org; Mon, 27 Mar 2006 11:50:24 -0500 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 1FNuvA-0006aU-LU for sip@ietf.org; Mon, 27 Mar 2006 11:50:24 -0500 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A7C703C8; Mon, 27 Mar 2006 11:50:15 -0500 From: "Hadriel Kaplan" To: "'Fredrik Thulin'" , Subject: RE: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Mon, 27 Mar 2006 11:50:24 -0500 Message-ID: <009f01c651be$8b65d2a0$6501a8c0@acmepacket.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: <200603270926.04600.ft@it.su.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcZRb8S0QVsE0/xDTmWVI7N3hzN3OQAQbwTA X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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, my impression is that P2 may have to support understanding outbound. The proxy forwarding rules changed in outbound. If P2 doesn't support outbound, and is the one doing location lookups, it may fork requests to the same UA through P1a and P1b to reach the UA. (not that that's a huge deal I guess, but it sounds bad to me that P2 could always be forking requests) It's also a problem because outbound needs the edge proxies to support Path, and if P2 doesn't and it's the one doing location lookups it may not send the request through P1. (depending on how it does location lookups) Outbound also fundamentally changes the redundancy mechanism for failure support from what I think is the current norm, and this change affects the load and signaling distribution on registrars and proxies. So my guess is operators would prefer UAs only do outbound if the operator fully supports it. So to be safe I would think all the P's between the UA and the registrar have to "support" outbound. (note that doesn't mean they have to all handle stun nor add a Path) -hadriel p.s. although it's not in scope for this draft, for IMS you would lose the ability to use an I-CSCF which does not understand sip-outbound with P/S-CSCFs that do, but I don't think that's a real issue, is it? If the I-CSCF does not want to be in the session path, 3GPP can specify that it accepts the proxy-require: outbound but not add a path (which is compliant with this draft). The I-CSCF would not have to implement stun because per this draft only servers talking directly with UAs have to. But no matter what my guess is you'll want the i-cscf to "understand" outbound anyway for register routing purposes, and since the p-cscf and s-cscf have to change for outbound, updating the i-cscf is hardly more work. > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se] > Sent: Monday, March 27, 2006 2:26 AM > To: sip@ietf.org > Cc: Hadriel Kaplan; 'Jeroen van Bemmel'; 'Juha Heinanen'; 'Dean Willis' > Subject: Re: [Sip] How to indicate during proxy discovery that a > proxysupports"outbound" > > Proxy-Require: outbound won't work when the next-hop from the UA > supports outbound, but other proxies on the way to the home proxy > (registrar) does not. > > Consider the following : > > UA --- | --- P1 --- P2 --- Registrar > NAT > > P1 supports Outbound, and is there to help the UA traverse the NAT. > P2 is the proxy indicated in DNS for the UA's "home domain", but it > proxies all REGISTER requests to Registrar. P2 does not support > Outbound, and should not be required to do so. > > /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 27 12:31:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNvXI-00027E-8X; Mon, 27 Mar 2006 12:29:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNvXG-00026x-CG for sip@ietf.org; Mon, 27 Mar 2006 12:29:46 -0500 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 1FNvXG-0000Gh-2J for sip@ietf.org; Mon, 27 Mar 2006 12:29:46 -0500 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A10208FC; Mon, 27 Mar 2006 12:29:38 -0500 From: "Hadriel Kaplan" To: , Subject: RE: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" Date: Mon, 27 Mar 2006 12:29:47 -0500 Message-ID: <00af01c651c4$0bd7a6c0$6501a8c0@acmepacket.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: <8B1D53AEF7B03449A6D3771B3B7F850F02201AED@esebe103.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcZRcE5CQ1PkpbaoTOKVfarb5yuTxAAIQENgAAxgRkA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] > Sent: Monday, March 27, 2006 7:10 AM > To: ft@it.su.se; sip@ietf.org > Cc: jh@tutpro.com; dean.willis@softarmor.com > Subject: RE: [Sip] How to indicate during proxy discovery > thataproxysupports"outbound" > > >While outbound promotes ways for using multiple connections towards > >multiple proxies it does not yet address the problem of discovering > >those proxies > > ... so that if the service resolved is "SIP-O+D2X" then the UA > could open a separate connection towards the preferred proxy > at each priority level of the SRV records for the service. > This would be a change to RFC 3263 procedures, that result > connecting to only one single proxy and then exiting the search. > > Comments, please ? Yes, I would definitely prefer a mechanism which allows the UA to discover the primary/backup dynamically rather than through more configuration, and it allows the operator to control support of the new redundancy model. The only other way to do the latter I could think of would be with 2 option-tags for supported (e.g., one for "outbound", one for "outbound-redundant"). But your way is cleaner, and lets the operator control how many redundant connections would be used. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 27 16:40:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNzPa-0005z1-Qy; Mon, 27 Mar 2006 16:38:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNzPZ-0005vP-3j for sip@ietf.org; Mon, 27 Mar 2006 16:38:05 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNzPY-0004wX-KV for sip@ietf.org; Mon, 27 Mar 2006 16:38:05 -0500 Received: (qmail 28906 invoked by uid 0); 27 Mar 2006 21:38:01 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 27 Mar 2006 21:38:01 -0000 Message-ID: <002801c651e6$b47a9c20$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Hadriel Kaplan" , , References: <00af01c651c4$0bd7a6c0$6501a8c0@acmepacket.com> Subject: Re: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Date: Mon, 27 Mar 2006 23:37:53 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 There are several arguments against the DNS SRV approach: - it still introduces a potential for misconfiguration (discrepancy between what is configured in DNS versus what's actually deployed and enabled) - it doesn't help proxies on the path to detect upstream support for STUN keepalive (unless each proxy would perform dynamic discovery too?) Perhaps it could be used in conjunction with the following (inspired by 'rport'): UAC : - REGISTER request: adds a 'keepalive' flag to the Via header - REGISTER response: checks top via for supported keepalive protocols Edge proxy / registrar: - REGISTER request: checks top Via in REGISTER for keepalive, if present adds 'keepalive' to its Via header when forwarding - REGISTER response: if request had keepalive, adds list of supported keepalive protocols to it At the registrar, if the top Via contains 'keepalive' it means that all proxies on the path support it. Perhaps this should be conveyed to the UAC in some way. Other than that, upon return the 'keepalive' lists the supported keepalive mechanisms. It would be specific for the protocol used in the Via header. Both the UAC and edge proxies should use one of the supported keepalive mechanisms, preferrably TCP keepalive (which need not be explicitly in the list, as it does not require specific server functionality). Each path segment would use indepedent keepalives, which is good for performance reasons (several UACs could share the edge proxy, and it would only use 1 flow (with keepalive) towards the registrar). This would support an arbitrary number of proxies between the UAC and the registrar, even when some of them do not support outbound Example: REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/TCP 10.0.1.1;branch=z9hG4bKnashds7;keepalive Max-Forwards: 70 From: Callee ;tag=a73kszlfl To: Callee Call-ID: 1j9FpLxk3uxtm8tn@10.0.1.1 CSeq: 1 REGISTER Supported: path Route: Contact: ;+sip.instance="" ;reg-id=1 Content-Length: 0SIP/2.0 200 OK Via: SIP/2.0/TCP 10.0.1.1;branch=z9hG4bKnashds7;keepalive="stun" From: Callee ;tag=a73kszlfl To: Callee ;tag=b88sn Call-ID: 1j9FpLxk3uxtm8tn@10.0.1.1 CSeq: 1 REGISTER Supported: outbound Contact: ;+sip.instance="" ;reg-id=1 ;expires=3600 Content-Length: 0------------------- Secondly, consider a deployment with an edge proxy that does not support outbound, and a UAC / registrar that do (with NAT between the edge proxy and the UAC). I think this may represent a case that calls for an end-to-end keepalive mechanism (i.e. PING / OPTIONS / whatever) which is initiated by the UAC, and proxied by the edge proxy. This would refresh the NAT binding. Do we want to support this scenario too? Regards, Jeroen > > >> -----Original Message----- >> From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] >> Sent: Monday, March 27, 2006 7:10 AM >> To: ft@it.su.se; sip@ietf.org >> Cc: jh@tutpro.com; dean.willis@softarmor.com >> Subject: RE: [Sip] How to indicate during proxy discovery >> thataproxysupports"outbound" >> >> >While outbound promotes ways for using multiple connections towards >> >multiple proxies it does not yet address the problem of discovering >> >those proxies >> >> ... so that if the service resolved is "SIP-O+D2X" then the UA >> could open a separate connection towards the preferred proxy >> at each priority level of the SRV records for the service. >> This would be a change to RFC 3263 procedures, that result >> connecting to only one single proxy and then exiting the search. >> >> Comments, please ? > > Yes, I would definitely prefer a mechanism which allows the UA to discover > the primary/backup dynamically rather than through more configuration, and > it allows the operator to control support of the new redundancy model. > The > only other way to do the latter I could think of would be with 2 > option-tags > for supported (e.g., one for "outbound", one for "outbound-redundant"). > But > your way is cleaner, and lets the operator control how many redundant > connections would be used. > > -hadriel > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 27 17:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0cN-00075S-Rf; Mon, 27 Mar 2006 17:55:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0cM-00071n-7l for sip@ietf.org; Mon, 27 Mar 2006 17:55:22 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO0cK-0000Z3-Sd for sip@ietf.org; Mon, 27 Mar 2006 17:55:22 -0500 Received: from [64.101.173.129] ([64.101.173.129]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2RMtm5O031125 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 27 Mar 2006 16:55:49 -0600 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1BCB@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1BCB@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sip-outbound Date: Mon, 27 Mar 2006 16:55:35 -0600 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, "Drage, Keith \(Keith\)" , fwmiller@cornfed.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 On Mar 27, 2006, at 2:13 AM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > I was not at the face-to-face meeting, but from the mail discussion I > haven't seen a sign of consensus. Having been the judge-of-consensus at the meeting, I noted about 185 hands in favor of STUN and about 5 holding out for PING. That's a pretty strong rough consensus. Admittedly, some of the more vocal PING proponents weren't present, but my sense of the matter is that the wider body of opinion does favor pursuing the standardization of the STUN approach. There was also a clear sense that the community wanted to document a single path rather than a set of alternatives. We've had a lot of folks recently airing frustrations about our usual tendency to document all proposed solutions to every problem and the rather horrible interoperability problem that approach might (or may already have) lead to. -- Dean Willis Chair, SIP working group _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 27 18:07:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0mi-0005rm-G5; Mon, 27 Mar 2006 18:06:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0mh-0005rD-4N for sip@ietf.org; Mon, 27 Mar 2006 18:06:03 -0500 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 1FO0mg-000121-RD for sip@ietf.org; Mon, 27 Mar 2006 18:06:03 -0500 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id AFD4027C; Mon, 27 Mar 2006 18:05:56 -0500 From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" , Subject: RE: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Date: Mon, 27 Mar 2006 18:06:04 -0500 Message-ID: <00fb01c651f3$0642ed30$6501a8c0@acmepacket.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: <002801c651e6$b47a9c20$31713b51@BEMBUSTER> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcZR5rZVi4aZqT5IRyyV0pK+x5XsawAAJLKA X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Jeroen, (or perhaps, Goedenavond?) Comments inline... > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Monday, March 27, 2006 4:38 PM > To: Hadriel Kaplan; Erkki.Koivusalo@nokia.com; sip@ietf.org > Subject: Re: [Sip] How to indicate during proxy > discoverythataproxysupports"outbound" > > There are several arguments against the DNS SRV approach: > - it still introduces a potential for misconfiguration (discrepancy > between > what is configured in DNS versus what's actually deployed and enabled) Not a bad one though. If the UA gets an SRV for SIP, it does regular SIP. If it gets SIP-O, it does sip-outbound. If a non sip-outbound UA gets SIP-O, it ignores it. So the worst case is you get UAs that could be doing outbound but end up doing regular SIP. If you have no NATted users, no problem. If you relied on outbound as your only NAT traversal mechanism, you'll find out soon enough that you mis-configured DNS, and you have the staff to fix it, and they're trained. The problem is fixed in one step for everyone, and it was a problem you created. If users mis-configure their UAs and set the keepalive=stun flag, even if they are NOT behind NATs, you get STUN messages on proxies with undetermined results, appearing from numerous ports/addresses; then try to get a hold of all the users to fix it, using much more staff talking to untrained consumers. And the problem continues as you add more users. All along you supported RFC 3261 and the other relevant IETF specs, and the sip working group created a new, continuous problem for you until you update the proxies to the draft, or buy SBCs. Oh, wait... I like this problem. :) > - it doesn't help proxies on the path to detect upstream support for STUN > keepalive (unless each proxy would perform dynamic discovery too?) Downstream proxies don't need to know if upstream ones support stun. Only the first server the UA touches needs to support stun, no? That's per the draft too, I think. There is a latent issue that you may want to verify (all) the proxies support outbound, but no one else has agreed that may be needed. (multiple proxies are out of scope I think?) I was only saying if you knew the closest/first proxy did outbound, then you'd know it did stun. Knowing about the other proxies supporting outbound was a bonus. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 27 18:08:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0nS-00064u-AF; Mon, 27 Mar 2006 18:06:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0nR-00064p-7P for sip@ietf.org; Mon, 27 Mar 2006 18:06:49 -0500 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO0nQ-0001CL-Ua for sip@ietf.org; Mon, 27 Mar 2006 18:06:49 -0500 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 k2RN6hc17685; Mon, 27 Mar 2006 18:06:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-outbound Date: Mon, 27 Mar 2006 17:06:41 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0818C28A@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZR8cc/TdyFOadWTzawiJxpH9wjAwAACWHw From: "Francois Audet" To: "Dean Willis" , "Christer Holmberg \(\(JO/LMF\)\)" X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org, "Drage, Keith \(Keith\)" , fwmiller@cornfed.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 Agree. The last meeting did indeed produce a strong rough consensus that the way forward was STUN-over-SIP for both UDP and TCP. As one of the strongest proponent of the PING method, I think it is time to move on=20 and and rally behind the concensus. The community will be best served if we finalize sip-outbound rapidly. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Monday, March 27, 2006 14:56 > To: Christer Holmberg ((JO/LMF)) > Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com > Subject: Re: [Sip] draft-ietf-sip-outbound >=20 >=20 >=20 > On Mar 27, 2006, at 2:13 AM, Christer Holmberg ((JO/LMF)) wrote: >=20 > > > > Hi, > > > > I was not at the face-to-face meeting, but from the mail=20 > discussion I=20 > > haven't seen a sign of consensus. >=20 > Having been the judge-of-consensus at the meeting, I noted about 185 =20 > hands in favor of STUN and about 5 holding out for PING. >=20 > That's a pretty strong rough consensus. Admittedly, some of the more =20 > vocal PING proponents weren't present, but my sense of the matter is =20 > that the wider body of opinion does favor pursuing the =20 > standardization of the STUN approach. >=20 > There was also a clear sense that the community wanted to document a =20 > single path rather than a set of alternatives. We've had a lot of =20 > folks recently airing frustrations about our usual tendency to =20 > document all proposed solutions to every problem and the rather =20 > horrible interoperability problem that approach might (or may=20 > already =20 > have) lead to. >=20 > -- > Dean Willis > Chair, SIP working group >=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=20 > sip Use sipping@ietf.org for new developments on the=20 > 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 Mon Mar 27 18:11:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0pj-00077m-Sc; Mon, 27 Mar 2006 18:09:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0ph-00076J-KH for sip@ietf.org; Mon, 27 Mar 2006 18:09:09 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO0pg-0001KP-Dn for sip@ietf.org; Mon, 27 Mar 2006 18:09:09 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.6/8.12.11) with ESMTP id k2RN904x078321; Mon, 27 Mar 2006 18:09:04 -0500 (EST) From: "Brett Tate" To: "'Christer Holmberg'" , "'Jonathan Rosenberg'" , "'IETF SIP List'" Subject: RE: [Sip] comments on sip-connected-identity Date: Mon, 27 Mar 2006 18:09:00 -0500 Message-ID: <002301c651f3$6f1c8280$1d28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-PMX-IsInternal: True 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 > Didn't the update-without-sdp come up a while=20 > ago, when we discussed sessions without media etc? It has been discussed within various threads in sip and sip-implementors over the past several years. Because one of the purposes of UPDATE is = to alter media, some vendors interpreted rfc3311 to indicate UPDATE must contain an SDP. However such a requirement is not contained within = rfc3311 or rfc4028. > If one simply wants to update the remote target, using=20 > update, why would it be required to include a body? Per rfc3311, UPDATE is not required to include a body. However since Jonathan recently suggested otherwise (or I misinterpreted = his email), hopefully he will reply with some clarification or answers for = the following email. http://www1.ietf.org/mail-archive/web/sip/current/msg13593.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 27 18:49:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO1Qd-0005jg-3W; Mon, 27 Mar 2006 18:47:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO1Qb-0005jb-3R for sip@ietf.org; Mon, 27 Mar 2006 18:47:17 -0500 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 1FO1Qa-0002zT-R9 for sip@ietf.org; Mon, 27 Mar 2006 18:47:17 -0500 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A97D05E4; Mon, 27 Mar 2006 18:47:09 -0500 From: "Hadriel Kaplan" To: "'Francois Audet'" , Subject: RE: [Sip] draft-ietf-sip-outbound Date: Mon, 27 Mar 2006 18:47:18 -0500 Message-ID: <010d01c651f8$c8b32240$6501a8c0@acmepacket.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: <1ECE0EB50388174790F9694F77522CCF0818C28A@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcZR8cc/TdyFOadWTzawiJxpH9wjAwAACWHwAAFpCiA= X-Spam-Score: 0.1 (/) 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 Totally agree. And agree with Dean that one path is the best. So why is TCP keep-alive without STUN still an option? And why is there a user-configured flag for keepalive=stun instead of a sip-based (e.g. signaling) check, or dns-based (which is also the "sip" way, methinks) determination if the first-hop is outbound compliant? -hadriel > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, March 27, 2006 6:07 PM > To: Dean Willis; Christer Holmberg ((JO/LMF)) > Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com > Subject: RE: [Sip] draft-ietf-sip-outbound > > Agree. > > The last meeting did indeed produce a strong rough consensus that the > way forward was STUN-over-SIP for both UDP and TCP. > > As one of the strongest proponent of the PING method, I think it is time > to move on > and and rally behind the concensus. The community will be best served > if we finalize sip-outbound rapidly. > > > > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Monday, March 27, 2006 14:56 > > To: Christer Holmberg ((JO/LMF)) > > Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com > > Subject: Re: [Sip] draft-ietf-sip-outbound > > > > > > > > On Mar 27, 2006, at 2:13 AM, Christer Holmberg ((JO/LMF)) wrote: > > > > > > > > Hi, > > > > > > I was not at the face-to-face meeting, but from the mail > > discussion I > > > haven't seen a sign of consensus. > > > > Having been the judge-of-consensus at the meeting, I noted about 185 > > hands in favor of STUN and about 5 holding out for PING. > > > > That's a pretty strong rough consensus. Admittedly, some of the more > > vocal PING proponents weren't present, but my sense of the matter is > > that the wider body of opinion does favor pursuing the > > standardization of the STUN approach. > > > > There was also a clear sense that the community wanted to document a > > single path rather than a set of alternatives. We've had a lot of > > folks recently airing frustrations about our usual tendency to > > document all proposed solutions to every problem and the rather > > horrible interoperability problem that approach might (or may > > already > > have) lead to. > > > > -- > > Dean Willis > > Chair, SIP working group > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 27 19:07:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO1iX-0000fQ-Ef; Mon, 27 Mar 2006 19:05:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO1iW-0000fL-Tw for sip@ietf.org; Mon, 27 Mar 2006 19:05:48 -0500 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO1iW-00044k-Kg for sip@ietf.org; Mon, 27 Mar 2006 19:05:48 -0500 Received: from [192.168.1.101] (pool-70-17-203-185.balt.east.verizon.net [70.17.203.185]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k2S05hY23545; Mon, 27 Mar 2006 18:05:43 -0600 Subject: RE: [Sip] draft-ietf-sip-outbound From: "Frank W. Miller" To: Hadriel Kaplan In-Reply-To: <010d01c651f8$c8b32240$6501a8c0@acmepacket.com> References: <010d01c651f8$c8b32240$6501a8c0@acmepacket.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Mon, 27 Mar 2006 19:05:41 -0500 Message-Id: <1143504341.2711.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org, 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As I noted, dissent registered. Hi, ho, hi, ho, its off to implement I go... FM On Mon, 2006-03-27 at 18:47 -0500, Hadriel Kaplan wrote: > Totally agree. And agree with Dean that one path is the best. > So why is TCP keep-alive without STUN still an option? > > And why is there a user-configured flag for keepalive=stun instead of a > sip-based (e.g. signaling) check, or dns-based (which is also the "sip" way, > methinks) determination if the first-hop is outbound compliant? > > -hadriel > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, March 27, 2006 6:07 PM > > To: Dean Willis; Christer Holmberg ((JO/LMF)) > > Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com > > Subject: RE: [Sip] draft-ietf-sip-outbound > > > > Agree. > > > > The last meeting did indeed produce a strong rough consensus that the > > way forward was STUN-over-SIP for both UDP and TCP. > > > > As one of the strongest proponent of the PING method, I think it is time > > to move on > > and and rally behind the concensus. The community will be best served > > if we finalize sip-outbound rapidly. > > > > > > > > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Monday, March 27, 2006 14:56 > > > To: Christer Holmberg ((JO/LMF)) > > > Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com > > > Subject: Re: [Sip] draft-ietf-sip-outbound > > > > > > > > > > > > On Mar 27, 2006, at 2:13 AM, Christer Holmberg ((JO/LMF)) wrote: > > > > > > > > > > > Hi, > > > > > > > > I was not at the face-to-face meeting, but from the mail > > > discussion I > > > > haven't seen a sign of consensus. > > > > > > Having been the judge-of-consensus at the meeting, I noted about 185 > > > hands in favor of STUN and about 5 holding out for PING. > > > > > > That's a pretty strong rough consensus. Admittedly, some of the more > > > vocal PING proponents weren't present, but my sense of the matter is > > > that the wider body of opinion does favor pursuing the > > > standardization of the STUN approach. > > > > > > There was also a clear sense that the community wanted to document a > > > single path rather than a set of alternatives. We've had a lot of > > > folks recently airing frustrations about our usual tendency to > > > document all proposed solutions to every problem and the rather > > > horrible interoperability problem that approach might (or may > > > already > > > have) lead to. > > > > > > -- > > > Dean Willis > > > Chair, SIP working group > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 27 20:18:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO2p0-000771-1P; Mon, 27 Mar 2006 20:16:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO2oz-00072m-6l for sip@ietf.org; Mon, 27 Mar 2006 20:16:33 -0500 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 1FO2ox-0007DM-QW for sip@ietf.org; Mon, 27 Mar 2006 20:16:33 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 27 Mar 2006 17:16:31 -0800 X-IronPort-AV: i="4.03,136,1141632000"; d="scan'208"; a="317764261:sNHT35003892" 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 k2S1GU7Z023544; Mon, 27 Mar 2006 17:16:30 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Mar 2006 17:16:30 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.20.33]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Mar 2006 17:16:29 -0800 Message-Id: <4.3.2.7.2.20060327190257.03349140@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Mar 2006 19:16:27 -0600 To: "Dale R. Worley" , "McCalmont, Patti" From: "James M. Polk" Subject: RE: [Sip] comments on location conveyance draft In-Reply-To: <1143135310.12925.51.camel@cdhcp139.pingtel.com> References: <422D410BD61FC04185076AD99AA7207A01771F16@inilmx01.lgmt.trdo> <422D410BD61FC04185076AD99AA7207A01771F16@inilmx01.lgmt.trdo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 Mar 2006 01:16:29.0148 (UTC) FILETIME=[3DC829C0:01C65205] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 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 Dale and Patti Brian Rosen and I are also writing the Emergency Phone BCP out of the ECRIT WG. How about, in the interests of keeping most emergency related stuff in ECRIT docs, that we make sure the Location Conveyance doc doesn't prevent this disabling, and the Phone BCP makes this disabling strictly enforced like you want? This way your requirement is written where folks should know to look for emergency related features/functions, and we don't really cross WGs too much. I'm trying to maintain the balance I was told to maintain by one of the new RAI Area Directors that was at the ECRIT interim meeting (you can guess who) who reeeeeally wanted the Location doc to stay away from emergency related issues as much as possible. This is one I believe we can directly address in the Phone BCP doc to your liking. Is this a fair compromise? Or do you two still want this explicit in the Location doc? I also think we can add an informative reference in the location doc to the phone BCP doc for a pointer of where other work around this can be found. At 12:35 PM 3/23/2006 -0500, Dale R. Worley wrote: >On Wed, 2006-03-22 at 19:30 -0600, McCalmont, Patti wrote: > > A UAC MUST be prevented from disabling conveyance of location for > > an emergency call if local jurisdiction (laws of that particular > > country) requires it. > >I think a requirement like this should be put into the draft. Not >because I think that necessarily every UAC should follow this rule -- >there are a host of complex issues here -- but because stating this as a >requirement will tend to cause UACs to be non-compliant only when >someone gave the issue serious consideration, instead of being non- >compliant because the implementer overlooked the issue. > >(I would rephrase the requirement something like this: "A UAC MUST >convey its location for an emergency call if it is required by the local >jurisdiction.") > >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 Mon Mar 27 20:45:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO3FT-0000pz-Hj; Mon, 27 Mar 2006 20:43:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO3FS-0000pu-HD for sip@ietf.org; Mon, 27 Mar 2006 20:43:54 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO3FS-0007wX-4h for sip@ietf.org; Mon, 27 Mar 2006 20:43:54 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2S1dOg09007; Mon, 27 Mar 2006 20:39:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-outbound Date: Mon, 27 Mar 2006 19:43:46 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B1E7C80@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZPtSfjf3cpCg4FRYqLQ/oo0vWzSABwIgyAAB7s05A= From: "Samir Srivastava" To: "Christer Holmberg \(JO/LMF\)" , , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 The biggest objection for PING was " To achieve comparable performance, it doesn't look into the Proxy-Require tags ". This was looked by purists as SIP like protocol.=20 I saw on the outbound slides for the presentation on IETF site " With PING it is infeasible to analyze all situations and check that no harm is done. " What situations for sample were analyzed and it was not found working. Can we have those findings posted on the list. I remember seeing some emails before the meeting that people were not following the complete thread and there was complete disconnect in performance aspects itself. I am listing the summary of the email exchanges earlier below=20 1. With the modified proxies (PING Support), both approaches equally work fine. PING doesn't have support for Require. The sole purpose of PING is KEEP ALIVE, nothing else. Use OPTIONS for anything else with Require. Purists disagree but there alternate solution has binary stuff itself. 2. With MAX-FORWARDS trick, it should work with old proxies. This trick forces old proxies not to look into the message details. It is needed for *OLD PROXIES*. 3. The other objection was for Authrization. For the old proxies, Client can resubmit the request with creditenials.=20 Do we need authrization for KEEP ALIVE traffic ? STUN also has it.=20 If you need PING to be authorized, Compare it with MESSAGE-INTEGRITY option of STUN ? This is trade off, what we want from new proxies between Speed and Authrization .=20 It is agreed that old proxies will not be able to process that fast, but this hickup is with every new feature working with old stuff. E.g. when you add a new option tag and put in Require header in a Request, it requires extra trip all together with the proxies who don't support new extension and you rollback to old stuff.=20 4. Overload situation handling both are equally likely. SIP has 503 mechanism with some caveats. But there is nothing in STUN. Here PING has slide benefit of reuse of SIP overload mechanism easily. We need to address STUN overload separately in BEHAVE. 5. stun-keepalive flag advantage can be used for PING too with similar ping-keepalive flag.=20 Thx Samir -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: Monday, March 27, 2006 12:14 AM To: fwmiller@cornfed.com; Drage, Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Hi, I was not at the face-to-face meeting, but from the mail discussion I haven't seen a sign of consensus. I think we should get the pros and cons of each solution documented, and go from there. Maybe that study was done and discussed at the face-to-face meeting, but then I would ask Keith (or someone else) to share that study with the rest of us, so we can see what the facts the consensus was made based on. I am not saying that PING would be the best solution, but I do agree with Frank that one solution does not necessarily preclude others. Regards, Christer =20 -----Original Message----- From: Frank W. Miller [mailto:fwmiller@cornfed.com] Sent: 25. maaliskuuta 2006 4:37 To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-outbound On Sat, 2006-03-25 at 00:51 +0000, Drage, Keith (Keith) wrote: > (as chair) >=20 > As a result of the face-to-face meeting held at IETF #65, we agreed in the room on the keepalive mechanism: >=20 > - OS TCP KeepAlive should be used if the client supports it. > - Need something more because OS TCP KeepAlive is not supported in every client OS. > - Consensus to use STUN for UDP > - Consensus to use STUN for TCP, with use of OS TCP keep alive above. >=20 > 2) Working group: Any dissent to the agreements listed above or do we have rough consensus to proceed according to the agreements made in the meeting >=20 I have dissent on the use of STUN exclusively for keepalive. I believe that a SIP based mechanism such as the PING draft I proposed is a better solution. The essence of my objection is that I think it is a mistake to have both STUN and SIP residing on the same port. I think this makes little sense for three reasons: 1) its architecturally in conflict with the way most other protocols are defined, i.e. each protocol generally lives on its own port, 2) it unnecessarily complicates implementations when there is a very simple way to do it within SIP, and most importantly 3) it is going to make it very difficult to use STUN for the same task with other protocols that will need keepalives. Also, I don't believe that the performance issues that have been put forth are substantive enough to cause the architectural violations that result from using STUN this way. If the group is dead set on using STUN this way, the SIP way should at least be acknowledged by 1) including a ;keepalive=3Dping tag for the = URI in the outbound draft and 2) allowing the PING draft to become an ietf draft. These actions place very little additional burden on implementors and will allow the "market" to decide which is the right one to be used operationally. Dissent registered. 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 27 20:49:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO3J8-0005nq-VX; Mon, 27 Mar 2006 20:47:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO3J6-0005mB-OI for sip@ietf.org; Mon, 27 Mar 2006 20:47:40 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO3J6-000829-F5 for sip@ietf.org; Mon, 27 Mar 2006 20:47:40 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2S1lZp18172; Mon, 27 Mar 2006 20:47:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-outbound Date: Mon, 27 Mar 2006 19:47:32 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B1E7C83@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZR8cc/TdyFOadWTzawiJxpH9wjAwAACWHwAAXb7YA= From: "Samir Srivastava" To: "Francois Audet" , "Dean Willis" , "Christer Holmberg \(\(JO/LMF\)\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip@ietf.org, "Drage, Keith \(Keith\)" , fwmiller@cornfed.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 agree. But need concrete info where PING was bad. Thx Samir=20 -----Original Message----- From: Audet, Francois [SC100:3055:EXCH]=20 Sent: Monday, March 27, 2006 3:07 PM To: Dean Willis; Christer Holmberg ((JO/LMF)) Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com Subject: RE: [Sip] draft-ietf-sip-outbound Agree. The last meeting did indeed produce a strong rough consensus that the way forward was STUN-over-SIP for both UDP and TCP. As one of the strongest proponent of the PING method, I think it is time to move on and and rally behind the concensus. The community will be best served if we finalize sip-outbound rapidly. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Monday, March 27, 2006 14:56 > To: Christer Holmberg ((JO/LMF)) > Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com > Subject: Re: [Sip] draft-ietf-sip-outbound >=20 >=20 >=20 > On Mar 27, 2006, at 2:13 AM, Christer Holmberg ((JO/LMF)) wrote: >=20 > > > > Hi, > > > > I was not at the face-to-face meeting, but from the mail=20 > discussion I=20 > > haven't seen a sign of consensus. >=20 > Having been the judge-of-consensus at the meeting, I noted about 185 =20 > hands in favor of STUN and about 5 holding out for PING. >=20 > That's a pretty strong rough consensus. Admittedly, some of the more =20 > vocal PING proponents weren't present, but my sense of the matter is =20 > that the wider body of opinion does favor pursuing the =20 > standardization of the STUN approach. >=20 > There was also a clear sense that the community wanted to document a =20 > single path rather than a set of alternatives. We've had a lot of =20 > folks recently airing frustrations about our usual tendency to =20 > document all proposed solutions to every problem and the rather =20 > horrible interoperability problem that approach might (or may=20 > already =20 > have) lead to. >=20 > -- > Dean Willis > Chair, SIP working group >=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=20 > sip Use sipping@ietf.org for new developments on the=20 > 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 Mar 28 01:11:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7Nd-0002pw-Fo; Tue, 28 Mar 2006 01:08:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7Nb-0002o0-CR for sip@ietf.org; Tue, 28 Mar 2006 01:08:35 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO7Na-00018A-0P for sip@ietf.org; Tue, 28 Mar 2006 01:08:35 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 19A423BEC6; Tue, 28 Mar 2006 08:08:33 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27016-01-7; Tue, 28 Mar 2006 08:08:32 +0200 (CEST) Received: from [192.168.123.15] (c-0cfbe055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.251.12]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id B6A853BEC0; Tue, 28 Mar 2006 08:08:32 +0200 (CEST) From: Fredrik Thulin To: "Hadriel Kaplan" Subject: Re: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Tue, 28 Mar 2006 08:08:12 +0200 User-Agent: KMail/1.9.1 References: <009f01c651be$8b65d2a0$6501a8c0@acmepacket.com> In-Reply-To: <009f01c651be$8b65d2a0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603280808.12109.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.489 tagged_above=-99 required=7 tests=[AWL=0.176, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 For reference : > > Consider the following : > > > > UA --- | --- P1 --- P2 --- Registrar > > NAT On Monday 27 March 2006 18:50, Hadriel Kaplan wrote: > Actually, my impression is that P2 may have to support understanding > outbound. The proxy forwarding rules changed in outbound. My impression is that the edge proxys, and the ones doing location service lookups, have to support Outbound - not any intermediate proxys. This is a good thing IMO. > If P2 > doesn't support outbound, and is the one doing location lookups, it > may fork requests to the same UA through P1a and P1b to reach the UA. Yes, in another scenario than the one I put forward this would perhaps be true, but I haven't said that P2 would need to support Outbound _if it was a proxy that did location service lookups_. ... > So to be safe I would think all the P's between the UA and the > registrar have to "support" outbound. (note that doesn't mean they > have to all handle stun nor add a Path) I don't give much for the 'let's just say every proxy needs to support every extension'. If Outbound can be made to work with 'just' the edge proxys and the proxys doing location service read/writes supporting Outbound, then I think that is the right thing. I'd say that this is the case currently - all the routing logic in the current Outbound draft would work without P2 supporting Outbound. The question now is how the UA could discover that P1 supports STUN keepalives, or something else. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 28 01:16:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7T7-0004MT-US; Tue, 28 Mar 2006 01:14:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7T6-0004MO-HV for sip@ietf.org; Tue, 28 Mar 2006 01:14:16 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO7Sz-0001K7-1s for sip@ietf.org; Tue, 28 Mar 2006 01:14:16 -0500 Received: (qmail 28971 invoked by uid 0); 28 Mar 2006 06:14:07 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 28 Mar 2006 06:14:07 -0000 Message-ID: <002a01c6522e$cd4c9800$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Hadriel Kaplan" , "'Juha Heinanen'" References: <005101c6514c$787b51f0$6501a8c0@acmepacket.com> Subject: Re: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Tue, 28 Mar 2006 08:13:58 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org, '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 >> So in summary, the mechanism I would propose at the UAC for detection of >> outbound support: >> don't add 'keepalive=xxx' to the configured outbound proxy URI, instead >> first check for Path headers containing a TBD flag (say "outbound"). If >> there are no Path headers, check for Supported: outbound > > But there are 3261 compliant proxies out there that don't support Path. > So > you will not know if the register went through one of those and hit an > outbound registrar, vs. there was no proxy. I think a proxy-require is > the > only safe bet (and it would work across multiple proxies). It only means > an > extra round-trip if it fails, and the truth is you do require the proxy to > support something, so why not use the header defined for that? If the outbound proxy does not support Path, it also does not support outbound. In either case the UAC could detect this (i.e. no Path header matching outbound proxy -> proxy does not support outbound). The problem could be with proxies that ~do~ support Path, but for one reason or another do not wish to be in the path for inbound requests. On the other hand: keepalive is only required for the path that inbound requests follow! So even in a (complex) setup like the following: UAC - P1 - P2 - registrar where P1 does not add a Path header, the UAC would be required to keep alive the connection towards P2 (indeed, set one up in case of TCP) RFC3327 currently says that the UAC can ignore Path headers in the REGISTER response. If scenario's as the one sketched above are to be supported, it seems like it will have to inspect them, find the last value, and use keepalive towards that hop. This also has security implications. This is getting complicated. In my opinion, the outbound draft at least has to be very specific about the types of deployments that it supports, and the assumptions made about intermediate proxies. It currently covers 2 cases: 1. Single Registrar and UA (section 3.2) 2. Edge Proxies with UAC directly behind NAT (section 3.4) There are at least 2 cases missing: 3. (2) with NAT after the edge proxies (edge proxies would need to do keepalive for this) 4. a chain of edge proxies (as in RFC3327 section 5.5.1), in particular when some of these don't add Path (and/or don't support outbound); UAC would need to do keepalive towards last Path entry 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 Mar 28 01:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7r2-0008Nb-PL; Tue, 28 Mar 2006 01:39:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7qF-00089t-7e for sip@ietf.org; Tue, 28 Mar 2006 01:38:11 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO7hV-0001cP-88 for sip@ietf.org; Tue, 28 Mar 2006 01:29:11 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 12F7A13FFF0; Tue, 28 Mar 2006 09:29:08 +0300 (EEST) Received: from rautu (isozyme127.gprs.dnafinland.fi [62.78.107.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id CACA713FFEA; Tue, 28 Mar 2006 09:29:00 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 73D02F15A8; Tue, 28 Mar 2006 09:29:35 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17448.55247.103128.728243@rautu.tutpro.com> Date: Tue, 28 Mar 2006 09:29:35 +0300 From: Juha Heinanen To: Subject: RE: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F02201AED@esebe103.NOE.Nokia.com> References: <200603270926.04600.ft@it.su.se> <8B1D53AEF7B03449A6D3771B3B7F850F02201AED@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, ft@it.su.se, 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 Erkki.Koivusalo@nokia.com writes: > But apart that I believe this would be the way to go i.e. to > define a few new NAPTR service types for Outbound, something like: > > "SIPS-O+D2T" "SIP-O+D2T" "SIP-O+D2U" erkki, many UAs on the market don't currently do NAPTR lookups, but only SRV lookups. so perhaps it would be easier for both implementation and standardization reasons to introduce _sip_out._proto.domain SRV records in addition to current _sip._proto.domain SRV records. by the way, no matter what kind of DNS solution is selected, one addition advantage of DNS is that separate proxies could be installed for use by local SIP UAs and foreign SIP UAs and peers. that is, local SIP UAs would make _sip_out._proto.domain SRV queries and foreign ones would keep on querying _sip._proto.domain SRV records. -- 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 Mar 28 01:45:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7ud-0001IO-1T; Tue, 28 Mar 2006 01:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7uc-0001IJ-9V for sip@ietf.org; Tue, 28 Mar 2006 01:42:42 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO7uZ-000225-UN for sip@ietf.org; Tue, 28 Mar 2006 01:42:42 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2S6gbfM028251; Tue, 28 Mar 2006 00:42:38 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Mar 2006 07:42:37 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012749372@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Tue, 28 Mar 2006 07:42:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Sip] draft-ietf-sipping-certs X-BeenThere: sip@ietf.org X-Mailman-Version: 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) Despite its name the above draft belongs to the SIP WG. Now that Cullen has moved on to better and higher things, it has been appropriate for the WG chairs to appoint a new editor for this document. The WG chairs would therefore like to announce that Jason Fischl will take over as editor for this document. Jason is asked to revise the document and resubmit as draft-ietf-sip-certs as soon as possible. regards Keith Keith Drage drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 28 01:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7yb-0003ee-Gp; Tue, 28 Mar 2006 01:46:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7yZ-0003dI-Cp for sip@ietf.org; Tue, 28 Mar 2006 01:46:47 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO7yV-00029c-0J for sip@ietf.org; Tue, 28 Mar 2006 01:46:47 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWT00M01S6RE2@siemenscomms.co.uk> for sip@ietf.org; Tue, 28 Mar 2006 07:47:15 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWT00L2NS6RGJ@siemenscomms.co.uk>; Tue, 28 Mar 2006 07:47:15 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Mar 2006 07:46:41 +0100 Content-return: allowed Date: Tue, 28 Mar 2006 07:46:30 +0100 From: "Elwell, John" Subject: RE: [Sip] comments on sip-connected-identity To: Brett Tate , 'Christer Holmberg' , 'Jonathan Rosenberg' , 'IETF SIP List' Message-id: <50B1CBA96870A34799A506B2313F2667088028DD@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT 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 Brett, I am getting confused by this thread. In my opinion Jonathan clearly stated that UPDATE without SDP offer is allowed. John > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: 28 March 2006 00:09 > To: 'Christer Holmberg'; 'Jonathan Rosenberg'; 'IETF SIP List' > Subject: RE: [Sip] comments on sip-connected-identity > > > Didn't the update-without-sdp come up a while > > ago, when we discussed sessions without media etc? > > It has been discussed within various threads in sip and > sip-implementors > over the past several years. Because one of the purposes of > UPDATE is to > alter media, some vendors interpreted rfc3311 to indicate UPDATE must > contain an SDP. However such a requirement is not contained > within rfc3311 > or rfc4028. > > > > If one simply wants to update the remote target, using > > update, why would it be required to include a body? > > Per rfc3311, UPDATE is not required to include a body. > > However since Jonathan recently suggested otherwise (or I > misinterpreted his > email), hopefully he will reply with some clarification or > answers for the > following email. > > http://www1.ietf.org/mail-archive/web/sip/current/msg13593.html > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 28 01:55:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO84D-0006ok-Cs; Tue, 28 Mar 2006 01:52:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO84B-0006lv-7Q for sip@ietf.org; Tue, 28 Mar 2006 01:52:35 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO849-0002Kd-TB for sip@ietf.org; Tue, 28 Mar 2006 01:52:35 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWT00001SGC8N@siemenscomms.co.uk> for sip@ietf.org; Tue, 28 Mar 2006 07:53:01 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWT00L6WSGCGJ@siemenscomms.co.uk>; Tue, 28 Mar 2006 07:53:00 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Mar 2006 07:52:26 +0100 Content-return: allowed Date: Tue, 28 Mar 2006 07:51:38 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-ietf-sip-outbound To: Dean Willis , Christer Holmberg Message-id: <50B1CBA96870A34799A506B2313F2667088028E1@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org, "Drage, Keith \(Keith\)" , fwmiller@cornfed.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 Dean, I agree. We have picked a solution and now we really need to move ahead with this important draft. John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 27 March 2006 23:56 > To: Christer Holmberg > Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com > Subject: Re: [Sip] draft-ietf-sip-outbound > > > On Mar 27, 2006, at 2:13 AM, Christer Holmberg ((JO/LMF)) wrote: > > > > > Hi, > > > > I was not at the face-to-face meeting, but from the mail > discussion I > > haven't seen a sign of consensus. > > Having been the judge-of-consensus at the meeting, I noted about 185 > hands in favor of STUN and about 5 holding out for PING. > > That's a pretty strong rough consensus. Admittedly, some of the more > vocal PING proponents weren't present, but my sense of the matter is > that the wider body of opinion does favor pursuing the > standardization of the STUN approach. > > There was also a clear sense that the community wanted to document a > single path rather than a set of alternatives. We've had a lot of > folks recently airing frustrations about our usual tendency to > document all proposed solutions to every problem and the rather > horrible interoperability problem that approach might (or may > already > have) lead to. > > -- > Dean Willis > Chair, SIP working group > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 28 02:13:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO8LW-00076k-2H; Tue, 28 Mar 2006 02:10:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO8LP-0006xB-6r for sip@ietf.org; Tue, 28 Mar 2006 02:10:23 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO8LL-0002zA-MA for sip@ietf.org; Tue, 28 Mar 2006 02:10:23 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2S7A3cl020986; Tue, 28 Mar 2006 10:10:04 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 10:10:18 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 10:10:17 +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] How to indicate during proxy discovery that aproxysupports"outbound" Date: Tue, 28 Mar 2006 10:10:16 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02201ECA@esebe103.NOE.Nokia.com> In-Reply-To: <17448.55247.103128.728243@rautu.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Thread-Index: AcZSMRO2MSlb3D/GT+ucp667+4DeAwAAbFxg From: To: X-OriginalArrivalTime: 28 Mar 2006 07:10:17.0779 (UTC) FILETIME=[AB083030:01C65236] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: sip@ietf.org, ft@it.su.se, 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 Juha, I have also thought about the option you outlined but I found some complication with it at least for those UAs that do support NAPTR processing according to RFC 3263. Should NAPTR only have those good old services "SIPS+D2T", "SIP+D2T" and "SIP+D2U" or should the new "-O" services be introduced additionally to the new types of SRV records ? I would like to start with the first case (trying to avoid introducing new concepts to both NAPTR and SRV): So let's assume that DNS has been configured with both _sip._proto.domain and _sip_out._proto.domain SRV records. What should the NAPTR query for domain in that case return=20 for e.g. "SIP+D2U" ? - If it returns both _sip._proto.domain and _sip_out._proto.domain then the same proxy servers might appear within the SRV records twice. Not good. Further on the UAs wanting Outbound service would need to discard _sip._proto.domain SRV records before sorting them as described in RFC 2782. Not nice either. - If it only returns _sip_out._proto.domain records then the UAs expecting Outbound support would be happy. However if=20 there is any reason for an UA to try finding or using a proxy without Outbound, then it turns out to be impossible with=20 NAPTR. This sounds too restrictive to me and would not allow the use case outlined by Fredrik: > A real life example : I want people trying to reach my users > to look up NAPTR/SRV for 'it.su.se' (naturally) but I want my=20 > clients to use other servers, currently indicated by NAPTR/SRV=20 > records for 'out.sip.su.se' because these other servers do=20 > stuff like Outbound, which the 'it.su.se' servers does not. So I would think, additionally to introducing the new type of SRV records, the new NAPTR service types would anyway be necessary. Then the question is, are those new types of SRV records _really_ needed as they would add one extra piece of new specification, complexity and source of errors for DNS configuration ? >many UAs on the market don't currently do NAPTR lookups,=20 >but only SRV lookups. But those UAs do not support Outbound either (as we are just now specifying it). So the real issue boils down to this: Will implementing NAPTR support for those UAs be really so much more difficult than implementing other new aspects of Outbound (URN instance ID creation, STUN keepalives, flow recovery, changes of DNS SRV record usage for using=20 backup proxies) so that there is no way for the Outbound=20 to rely on NAPTR ? After running a project that implemented NAPTR to an UA I do not find this too hard, unless the OS on top of which the UA SW is running does simply not support DNS NAPTR RRs. In my opinion the solution you suggest is possible but not very elegant as NAPTR RRs can not be ignored. Regards, Erkki >-----Original Message----- >From: ext Juha Heinanen [mailto:jh@tutpro.com]=20 >Sent: 28.March.2006 09:30 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: ft@it.su.se; sip@ietf.org; dean.willis@softarmor.com >Subject: RE: [Sip] How to indicate during proxy discovery that=20 >aproxysupports"outbound" > >Erkki.Koivusalo@nokia.com writes: > > > But apart that I believe this would be the way to go i.e. to > > define a few new NAPTR service types for Outbound, something like: > >=20 > > "SIPS-O+D2T" "SIP-O+D2T" "SIP-O+D2U" > >erkki, > >many UAs on the market don't currently do NAPTR lookups, but only SRV >lookups. so perhaps it would be easier for both implementation and >standardization reasons to introduce _sip_out._proto.domain SRV records >in addition to current _sip._proto.domain SRV records. > >by the way, no matter what kind of DNS solution is selected, one >addition advantage of DNS is that separate proxies could be installed >for use by local SIP UAs and foreign SIP UAs and peers. that is, local >SIP UAs would make _sip_out._proto.domain SRV queries and foreign ones >would keep on querying _sip._proto.domain SRV records. > >-- 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 Mar 28 02:36:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO8iO-0003Te-2m; Tue, 28 Mar 2006 02:34:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO8iM-0003SV-Er for sip@ietf.org; Tue, 28 Mar 2006 02:34:06 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO8iL-00041Z-HO for sip@ietf.org; Tue, 28 Mar 2006 02:34:06 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5CEF44F0001; Tue, 28 Mar 2006 09:34:04 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 09:34:03 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 09:34: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] draft-ietf-sip-outbound Date: Tue, 28 Mar 2006 09:34:02 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1BDB@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZSNDA3lyqvu5F1T3S0MlhvKLD2ggABJ8JA From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Dean Willis" X-OriginalArrivalTime: 28 Mar 2006 07:34:03.0322 (UTC) FILETIME=[FCB8C9A0:01C65239] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sip@ietf.org, "Drage, Keith \(Keith\)" , fwmiller@cornfed.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, It is ok to pick a solution. What I asked for was some kind of technical justification why a specific solution was chosen, and what possible assumptions (when it comes to architecture issues etc) may have been identified. Because, I really hope there was some technical arguments behind the choise to vote for STUN. ...eeh... sorry, "lift a hand" for STUN ;) Also, the solutions discussed seem to be the ones related to UA initiated keep-alive. I raised the question whether a solution where the network would initiate the keep-alives would be feasible. Maybe I've missed some replies to that mail, but has it been agreed that such solution wouldn't work, and/or is bad, and/or does not need to be specified in the first place? Regards, Christer =20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: 28. maaliskuuta 2006 9:52 To: Dean Willis; Christer Holmberg (JO/LMF) Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com Subject: RE: [Sip] draft-ietf-sip-outbound Dean, I agree. We have picked a solution and now we really need to move ahead with this important draft. John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 27 March 2006 23:56 > To: Christer Holmberg > Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com > Subject: Re: [Sip] draft-ietf-sip-outbound >=20 >=20 > On Mar 27, 2006, at 2:13 AM, Christer Holmberg ((JO/LMF)) wrote: >=20 > > > > Hi, > > > > I was not at the face-to-face meeting, but from the mail > discussion I > > haven't seen a sign of consensus. >=20 > Having been the judge-of-consensus at the meeting, I noted about 185=20 > hands in favor of STUN and about 5 holding out for PING. >=20 > That's a pretty strong rough consensus. Admittedly, some of the more=20 > vocal PING proponents weren't present, but my sense of the matter is=20 > that the wider body of opinion does favor pursuing the standardization > of the STUN approach. >=20 > There was also a clear sense that the community wanted to document a=20 > single path rather than a set of alternatives. We've had a lot of=20 > folks recently airing frustrations about our usual tendency to=20 > document all proposed solutions to every problem and the rather=20 > horrible interoperability problem that approach might (or may already > have) lead to. >=20 > -- > Dean Willis > Chair, SIP working group >=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 Mar 28 02:38:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO8kh-0004OE-8a; Tue, 28 Mar 2006 02:36:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO8kg-0004O7-Fw for sip@ietf.org; Tue, 28 Mar 2006 02:36:30 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO8kf-00045c-UM for sip@ietf.org; Tue, 28 Mar 2006 02:36:30 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2S7aBPr026456; Tue, 28 Mar 2006 10:36:11 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 10:36:25 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 10:36:25 +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-outbound Date: Tue, 28 Mar 2006 10:36:24 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02201F39@esebe103.NOE.Nokia.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B1E7C83@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZR8cc/TdyFOadWTzawiJxpH9wjAwAACWHwAAXb7YAAC7nakA== From: To: , , , X-OriginalArrivalTime: 28 Mar 2006 07:36:25.0314 (UTC) FILETIME=[515B0C20:01C6523A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: sip@ietf.org, drage@lucent.com, fwmiller@cornfed.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 am happy to see the WG to gradually gain rough consensus also on the mailing list. Here are some comments for a couple of issues that you raised: > 3. The other objection was for Authrization. For the old=20 > proxies, Client can resubmit the request with creditenials.=20 > Do we need authrization for KEEP ALIVE traffic ?=20 No we definitely do not need it, and the fact that it would be difficult to disable authorization for PING (considering the old proxies that do not recognize the method) would just dilute the argument of PING being backwards compatible towards old proxies. It might be, but there are known risks. > STUN also has it ... compare it with MESSAGE-INTEGRITY > option of STUN ? Latest STUN bis introduces STUN usage for NAT keepalive and there is still an open question if the integrity check would be needed. My opinion is that for this purpose the integrity check could be disabled. The username and password used for STUN integrity can be used for 24 hours. Issue: do we need message integrity for keepalives when doing STUN and SIP on the same port? > 5. stun-keepalive flag advantage can be used for=20 > PING too with similar ping-keepalive flag.=20 There is currently another thread with subject RE: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" If the conclusion of the thread is that discovery would be done with DNS (and if there is just STUN keepalive mechanism specified) then Outbound could drop the keepalive flags alltogether. At least I could not any more find use for them, to be used within the protocol between UA and network. Regards, Erkki >-----Original Message----- >From: ext Samir Srivastava [mailto:samirsr@nortel.com]=20 >Sent: 28.March.2006 04:48 >To: Francois Audet; Dean Willis; Christer Holmberg ((JO/LMF)) >Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com >Subject: RE: [Sip] draft-ietf-sip-outbound > >I agree. But need concrete info where PING was bad. > >Thx >Samir=20 > >-----Original Message----- >From: Audet, Francois [SC100:3055:EXCH]=20 >Sent: Monday, March 27, 2006 3:07 PM >To: Dean Willis; Christer Holmberg ((JO/LMF)) >Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com >Subject: RE: [Sip] draft-ietf-sip-outbound > >Agree. > >The last meeting did indeed produce a strong rough consensus that the >way forward was STUN-over-SIP for both UDP and TCP. > >As one of the strongest proponent of the PING method, I think=20 >it is time >to move on and and rally behind the concensus. The community will be >best served if we finalize sip-outbound rapidly. > > > > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com]=20 >> Sent: Monday, March 27, 2006 14:56 >> To: Christer Holmberg ((JO/LMF)) >> Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com >> Subject: Re: [Sip] draft-ietf-sip-outbound >>=20 >>=20 >>=20 >> On Mar 27, 2006, at 2:13 AM, Christer Holmberg ((JO/LMF)) wrote: >>=20 >> > >> > Hi, >> > >> > I was not at the face-to-face meeting, but from the mail=20 >> discussion I=20 >> > haven't seen a sign of consensus. >>=20 >> Having been the judge-of-consensus at the meeting, I noted=20 >about 185 =20 >> hands in favor of STUN and about 5 holding out for PING. >>=20 >> That's a pretty strong rough consensus. Admittedly, some of=20 >the more =20 >> vocal PING proponents weren't present, but my sense of the=20 >matter is =20 >> that the wider body of opinion does favor pursuing the =20 >> standardization of the STUN approach. >>=20 >> There was also a clear sense that the community wanted to=20 >document a =20 >> single path rather than a set of alternatives. We've had a lot of =20 >> folks recently airing frustrations about our usual tendency to =20 >> document all proposed solutions to every problem and the rather =20 >> horrible interoperability problem that approach might (or may=20 >> already =20 >> have) lead to. >>=20 >> -- >> Dean Willis >> Chair, SIP working group >>=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=20 >> sip Use sipping@ietf.org for new developments on the=20 >> 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 28 04:23:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOAOc-0006FV-HS; Tue, 28 Mar 2006 04:21:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOAOa-0006FQ-Ve for sip@ietf.org; Tue, 28 Mar 2006 04:21:48 -0500 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOAOa-0008FA-Iw for sip@ietf.org; Tue, 28 Mar 2006 04:21:48 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2S9Lh611742; Tue, 28 Mar 2006 04:21:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-outbound Date: Tue, 28 Mar 2006 03:21:40 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B1E7D86@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZR8cc/TdyFOadWTzawiJxpH9wjAwAACWHwAAXb7YAAC7nakAACktLA From: "Samir Srivastava" To: , "Francois Audet" , , X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: sip@ietf.org, drage@lucent.com, fwmiller@cornfed.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 am happy to see there are some who wants to discuss merits/demerits .... More in line below. Thx Samir -----Original Message----- From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 Sent: Monday, March 27, 2006 11:36 PM To: Srivastava, Samir [SC100:8826:EXCH]; Audet, Francois [SC100:3055:EXCH]; dean.willis@softarmor.com; christer.holmberg@ericsson.com Cc: sip@ietf.org; drage@lucent.com; fwmiller@cornfed.com Subject: RE: [Sip] draft-ietf-sip-outbound Hi, I am happy to see the WG to gradually gain rough consensus also on the mailing list. Here are some comments for a couple of issues that you raised: > 3. The other objection was for Authrization. For the old proxies,=20 > Client can resubmit the request with creditenials. > Do we need authrization for KEEP ALIVE traffic ?=20 No we definitely do not need it, and the fact that it would be difficult to disable authorization for PING (considering the old proxies that do not recognize the method) would just dilute the argument of PING being backwards compatible towards old proxies. It might be, but there are known risks. SS>> Even If PING needs to be authorized, but I have PING with MAX-FORWARDS =3D0, then It will not process the PING further and return 483 ( 3261 Section 16.3 item 3 last para).=20 Are you thinking anything else, please explain if so. > STUN also has it ... compare it with MESSAGE-INTEGRITY option of STUN=20 > ? Latest STUN bis introduces STUN usage for NAT keepalive and there is still an open question if the integrity check would be needed. My opinion is that for this purpose the integrity check could be disabled. The username and password used for STUN integrity can be used for 24 hours. Issue: do we need message integrity for keepalives when doing STUN and SIP on the same port? SS>> If I am bad guy, who sends the STUN keep alives, with changing / faked source IP, how we want to address it. Only initial handshake (Shared Secret)is over TLS, correct. I think Security section of outbound-03 needs to include attacks caused by "excessive keep alives, which don't adhere to described timers". One can signal to IDS/IPS if SIP 503 timer is not acknowledged repeatedly by a UA. What we do for STUN ? > 5. stun-keepalive flag advantage can be used for PING too with similar > ping-keepalive flag. There is currently another thread with subject RE: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" If the conclusion of the thread is that discovery would be done with DNS (and if there is just STUN keepalive mechanism specified) then Outbound could drop the keepalive flags alltogether. At least I could not any more find use for them, to be used within the protocol between UA and network. SS>> Fine. I am waiting for the decsion. This is minor point overall. I prefer less overloading, if we might find some problem ( e.g. PRACK discussions) then it is easy to fix. Regards, Erkki >-----Original Message----- >From: ext Samir Srivastava [mailto:samirsr@nortel.com] >Sent: 28.March.2006 04:48 >To: Francois Audet; Dean Willis; Christer Holmberg ((JO/LMF)) >Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com >Subject: RE: [Sip] draft-ietf-sip-outbound > >I agree. But need concrete info where PING was bad. > >Thx >Samir > >-----Original Message----- >From: Audet, Francois [SC100:3055:EXCH] >Sent: Monday, March 27, 2006 3:07 PM >To: Dean Willis; Christer Holmberg ((JO/LMF)) >Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com >Subject: RE: [Sip] draft-ietf-sip-outbound > >Agree. > >The last meeting did indeed produce a strong rough consensus that the=20 >way forward was STUN-over-SIP for both UDP and TCP. > >As one of the strongest proponent of the PING method, I think it is=20 >time to move on and and rally behind the concensus. The community will=20 >be best served if we finalize sip-outbound rapidly. > > > > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Monday, March 27, 2006 14:56 >> To: Christer Holmberg ((JO/LMF)) >> Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com >> Subject: Re: [Sip] draft-ietf-sip-outbound >>=20 >>=20 >>=20 >> On Mar 27, 2006, at 2:13 AM, Christer Holmberg ((JO/LMF)) wrote: >>=20 >> > >> > Hi, >> > >> > I was not at the face-to-face meeting, but from the mail >> discussion I >> > haven't seen a sign of consensus. >>=20 >> Having been the judge-of-consensus at the meeting, I noted >about 185 >> hands in favor of STUN and about 5 holding out for PING. >>=20 >> That's a pretty strong rough consensus. Admittedly, some of >the more >> vocal PING proponents weren't present, but my sense of the >matter is >> that the wider body of opinion does favor pursuing the=20 >> standardization of the STUN approach. >>=20 >> There was also a clear sense that the community wanted to >document a >> single path rather than a set of alternatives. We've had a lot of=20 >> folks recently airing frustrations about our usual tendency to=20 >> document all proposed solutions to every problem and the rather=20 >> horrible interoperability problem that approach might (or may already >> have) lead to. >>=20 >> -- >> Dean Willis >> Chair, SIP working group >>=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=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 Tue Mar 28 05:34:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOBV5-0007tX-7O; Tue, 28 Mar 2006 05:32:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOBV4-0007tS-64 for sip@ietf.org; Tue, 28 Mar 2006 05:32:34 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOBV3-0003cf-EG for sip@ietf.org; Tue, 28 Mar 2006 05:32:34 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2SAVKmY023156; Tue, 28 Mar 2006 13:31:20 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 13:32:04 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 13:32: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] draft-ietf-sip-outbound Date: Tue, 28 Mar 2006 13:32:01 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02202154@esebe103.NOE.Nokia.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B1E7D86@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZR8cc/TdyFOadWTzawiJxpH9wjAwAACWHwAAXb7YAAC7nakAACktLAAAJ2LuA= From: To: , , , X-OriginalArrivalTime: 28 Mar 2006 10:32:03.0783 (UTC) FILETIME=[DAC5CD70:01C65252] X-Spam-Score: 0.2 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: sip@ietf.org, drage@lucent.com, fwmiller@cornfed.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 am happy to see there are some who wants to discuss merits/demerits OK, even if I am not sure how long I would like to sustain the discussion as the consensus has more or less settled down and there is some other work also to be done ... I have to admit that I have not personally studied the related security implications deeply, but gave my comments based on=20 the arguments and counterarguments I had earlier seen in this thread. Anyway, here some more thoughts: >SS>> If I am bad guy, who sends the STUN keep alives, with changing / >faked source IP, how we want to address it. I am not sure what kind of harm this specific kind of attack would make. If the source IP is faked, then the NAT would not any more pass the STUN response from proxy back to the UA. The UA would only=20 correctly see the responses to its STUN request and detect flow failures accordingly. Remember that according to Outbound it is the responsibility of the UA to monitor the state of the flow and try re-establishing it if necessary. Or did you mean the case that the bad guy would monitor the UA sending STUN Binding Requests and send bad responses back before the proxy sends the good response ? In such a MITM attack the UA would try=20 re-registration after each keepalive. But if we would like to=20 prevent such an attack, STUN is definitely better than SIP PING as STUN allows the UA to authenticate the response while there is no such possibility for SIP responses. The cost however is that the proxy would be required to perform all the STUN processing for message integrity and authentication. I am not totally sure what is the cost-benefit ratio in this case, STUN with or without authentication sounds viable to me. >Security section of outbound-03 needs to include attacks caused by >"excessive keep alives, which don't adhere to described=20 >timers". If someone sends a massive amount of rogue PING or STUN keepalives=20 to proxy for a DoS attack, I do not think the used protocol really=20 makes a difference. >SS>> Even If PING needs to be authorized, but I have PING with >MAX-FORWARDS =3D0, then It will not process the PING further and return >483 ( 3261 Section 16.3 item 3 last para).=20 >Are you thinking anything else, please explain if so. Seems to me that it could be done like that. I do not have any further=20 comments to this, in addition to the discussion Jonathan already gave in the thread earlier: > So, a normal RFC3261 compliant proxy WILL NOT reject a PING=20 > request with a 501. You can force it to reject any request,=20 > including PING, by setting Max-Forwards to zero. But the point=20 > is, there is lots of other processing in a standard proxy that=20 > is going to interfere with your assumptions in this PING method. And at that point the discussion went to a number of other directions. Regards, Erkki >-----Original Message----- >From: ext Samir Srivastava [mailto:samirsr@nortel.com]=20 >Sent: 28.March.2006 12:22 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); Francois Audet;=20 >dean.willis@softarmor.com; christer.holmberg@ericsson.com >Cc: sip@ietf.org; drage@lucent.com; fwmiller@cornfed.com >Subject: RE: [Sip] draft-ietf-sip-outbound > >I am happy to see there are some who wants to discuss merits/demerits >.... > >More in line below. > >Thx >Samir > >-----Original Message----- >From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 >Sent: Monday, March 27, 2006 11:36 PM >To: Srivastava, Samir [SC100:8826:EXCH]; Audet, Francois >[SC100:3055:EXCH]; dean.willis@softarmor.com; >christer.holmberg@ericsson.com >Cc: sip@ietf.org; drage@lucent.com; fwmiller@cornfed.com >Subject: RE: [Sip] draft-ietf-sip-outbound > > >Hi, > >I am happy to see the WG to gradually gain rough consensus also on the >mailing list. Here are some comments for a couple of issues that you >raised: > >> 3. The other objection was for Authrization. For the old proxies,=20 >> Client can resubmit the request with creditenials. >> Do we need authrization for KEEP ALIVE traffic ?=20 > >No we definitely do not need it, and the fact that it would be=20 >difficult >to disable authorization for PING (considering the old proxies that do >not recognize the method) would just dilute the argument of PING being >backwards compatible towards old proxies. It might be, but there are >known risks. > >SS>> Even If PING needs to be authorized, but I have PING with >MAX-FORWARDS =3D0, then It will not process the PING further and return >483 ( 3261 Section 16.3 item 3 last para).=20 >Are you thinking anything else, please explain if so. > > >> STUN also has it ... compare it with MESSAGE-INTEGRITY=20 >option of STUN=20 >> ? > >Latest STUN bis introduces STUN usage for NAT keepalive and there is >still an open question if the integrity check would be needed. My >opinion is that for this purpose the integrity check could be disabled. > > The username and password used for STUN integrity can be used for 24 > hours. > > Issue: do we need message integrity for keepalives when doing > STUN and SIP on the same port? > >SS>> If I am bad guy, who sends the STUN keep alives, with changing / >faked source IP, how > we want to address it. Only initial handshake (Shared Secret)is >over TLS, correct. I think >Security section of outbound-03 needs to include attacks caused by >"excessive keep alives, which don't adhere to described=20 >timers". One can >signal to IDS/IPS if SIP 503 timer is not acknowledged repeatedly by a >UA. What we do for STUN ? > > >> 5. stun-keepalive flag advantage can be used for PING too=20 >with similar > >> ping-keepalive flag. > >There is currently another thread with subject >RE: [Sip] How to indicate during proxy discovery >thataproxysupports"outbound" > >If the conclusion of the thread is that discovery would be=20 >done with DNS >(and if there is just STUN keepalive mechanism >specified) then Outbound could drop the keepalive flags alltogether. >At least I could not any more find use for them, to be used within the >protocol between UA and network. > >SS>> Fine. I am waiting for the decsion. This is minor point overall. I >prefer less overloading, if we might find some problem ( e.g. PRACK >discussions) then it is easy to fix. > >Regards, > >Erkki > >>-----Original Message----- >>From: ext Samir Srivastava [mailto:samirsr@nortel.com] >>Sent: 28.March.2006 04:48 >>To: Francois Audet; Dean Willis; Christer Holmberg ((JO/LMF)) >>Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com >>Subject: RE: [Sip] draft-ietf-sip-outbound >> >>I agree. But need concrete info where PING was bad. >> >>Thx >>Samir >> >>-----Original Message----- >>From: Audet, Francois [SC100:3055:EXCH] >>Sent: Monday, March 27, 2006 3:07 PM >>To: Dean Willis; Christer Holmberg ((JO/LMF)) >>Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com >>Subject: RE: [Sip] draft-ietf-sip-outbound >> >>Agree. >> >>The last meeting did indeed produce a strong rough consensus that the=20 >>way forward was STUN-over-SIP for both UDP and TCP. >> >>As one of the strongest proponent of the PING method, I think it is=20 >>time to move on and and rally behind the concensus. The=20 >community will=20 >>be best served if we finalize sip-outbound rapidly. >> >> >> >> >> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> Sent: Monday, March 27, 2006 14:56 >>> To: Christer Holmberg ((JO/LMF)) >>> Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com >>> Subject: Re: [Sip] draft-ietf-sip-outbound >>>=20 >>>=20 >>>=20 >>> On Mar 27, 2006, at 2:13 AM, Christer Holmberg ((JO/LMF)) wrote: >>>=20 >>> > >>> > Hi, >>> > >>> > I was not at the face-to-face meeting, but from the mail >>> discussion I >>> > haven't seen a sign of consensus. >>>=20 >>> Having been the judge-of-consensus at the meeting, I noted >>about 185 >>> hands in favor of STUN and about 5 holding out for PING. >>>=20 >>> That's a pretty strong rough consensus. Admittedly, some of >>the more >>> vocal PING proponents weren't present, but my sense of the >>matter is >>> that the wider body of opinion does favor pursuing the=20 >>> standardization of the STUN approach. >>>=20 >>> There was also a clear sense that the community wanted to >>document a >>> single path rather than a set of alternatives. We've had a lot of=20 >>> folks recently airing frustrations about our usual tendency to=20 >>> document all proposed solutions to every problem and the rather=20 >>> horrible interoperability problem that approach might (or=20 >may already >>> have) lead to. >>>=20 >>> -- >>> Dean Willis >>> Chair, SIP working group >>>=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=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 Tue Mar 28 08:52:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOEaD-0000p6-Fm; Tue, 28 Mar 2006 08:50:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOEaB-0000p1-HB for sip@ietf.org; Tue, 28 Mar 2006 08:50:03 -0500 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 1FOEa9-0003DT-5S for sip@ietf.org; Tue, 28 Mar 2006 08:50:03 -0500 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id AEFA0194; Tue, 28 Mar 2006 08:49:46 -0500 Message-ID: <012601c6526e$7cf1cf20$800101df@acmepacket.com> From: "Bob Penfield" To: "Hadriel Kaplan" , "'Fredrik Thulin'" , References: <009f01c651be$8b65d2a0$6501a8c0@acmepacket.com> Subject: Re: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Date: Tue, 28 Mar 2006 08:49:51 -0500 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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 inline ----- Original Message ----- From: "Hadriel Kaplan" > > Actually, my impression is that P2 may have to support > understanding outbound. The proxy forwarding rules changed > in outbound. Intermediate proxies do not have to support outbound. The forwarding rules have changed for the registrar/home-proxy and the edge proxy, not for other intermediate proxies. P2 would see a Route header pointing at P1. > If P2 doesn't support outbound, and is the one > doing location lookups, it may fork requests to the same UA > through P1a and P1b to reach the UA. (not that that's a huge > deal I guess, but it sounds bad to me that P2 could always > be forking requests) If P2 is doing location lookups in the registrar (i.e. inbound requests go to P2 rather than the registrar), then it qualifies as the home proxy and would need to support outbound so that it would not fork the request. > > It's also a problem because outbound needs the edge proxies > to support Path, and if P2 doesn't and it's the one doing > location lookups it may not send the request through P1. > (depending on how it does location lookups) > > Outbound also fundamentally changes the redundancy mechanism > for failure support from what I think is the current norm, > and this change affects the load and signaling distribution > on registrars and proxies. So my guess is operators would > prefer UAs only do outbound if the operator fully supports it. > > So to be safe I would think all the P's between the UA and > the registrar have to "support" outbound. (note that doesn't > mean they have to all handle stun nor add a Path) Again, only the "home proxy" (the one that does location lookup in the registration data base), and the edge proxy (the one the UA has a direct connection to) need to support the outbound draft and Path. Intermediate proxies would see a Route header inserted by the home proxy on request inbound to the UA. Besides, if the intervening proxy did not add a Path header to the REGISTER, it probably would not even receive the inbound request. > > -hadriel > p.s. although it's not in scope for this draft, for IMS you > would lose the ability to use an I-CSCF which does not > understand sip-outbound with P/S-CSCFs that do, but I don't > think that's a real issue, is it? If the I-CSCF does not > want to be in the session path, 3GPP can specify that it > accepts the proxy-require: outbound but not add a path > (which is compliant with this draft). The I-CSCF would > not have to implement stun because per this draft only > servers talking directly with UAs have to. But no matter > what my guess is you'll want the i-cscf to "understand" > outbound anyway for register routing purposes, and since > the p-cscf and s-cscf have to change for outbound, updating > the i-cscf is hardly more work. > > >> -----Original Message----- >> From: Fredrik Thulin [mailto:ft@it.su.se] >> Sent: Monday, March 27, 2006 2:26 AM >> To: sip@ietf.org >> Cc: Hadriel Kaplan; 'Jeroen van Bemmel'; 'Juha Heinanen'; 'Dean Willis' >> Subject: Re: [Sip] How to indicate during proxy discovery that a >> proxysupports"outbound" >> >> Proxy-Require: outbound won't work when the next-hop from the UA >> supports outbound, but other proxies on the way to the home proxy >> (registrar) does not. >> >> Consider the following : >> >> UA --- | --- P1 --- P2 --- Registrar >> NAT >> >> P1 supports Outbound, and is there to help the UA traverse the NAT. >> P2 is the proxy indicated in DNS for the UA's "home domain", but it >> proxies all REGISTER requests to Registrar. P2 does not support >> Outbound, and should not be required to do so. >> >> /Fredrik > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 28 09:02:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOEkO-0004Dr-Uj; Tue, 28 Mar 2006 09:00:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOEkN-0004Bu-E0 for sip@ietf.org; Tue, 28 Mar 2006 09:00:35 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOEkM-0003Z9-SE for sip@ietf.org; Tue, 28 Mar 2006 09:00:35 -0500 Received: by tutpro.com (Postfix, from userid 65534) id 6E323140016; Tue, 28 Mar 2006 17:00:33 +0300 (EEST) Received: from rautu (anneal248.gprs.dnafinland.fi [62.78.105.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 80C56140014; Tue, 28 Mar 2006 17:00:24 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 038BFF15A8; Tue, 28 Mar 2006 17:01:06 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17449.16802.642384.111485@rautu.tutpro.com> Date: Tue, 28 Mar 2006 17:01:06 +0300 From: Juha Heinanen To: Subject: RE: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F02201ECA@esebe103.NOE.Nokia.com> References: <17448.55247.103128.728243@rautu.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F02201ECA@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sip@ietf.org, ft@it.su.se, 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 Erkki.Koivusalo@nokia.com writes: > Should NAPTR only have those good old services "SIPS+D2T", > "SIP+D2T" and "SIP+D2U" or should the new "-O" services > be introduced additionally to the new types of SRV records ? erkki, i guess we would need to introduce new "O" NAPTR service types to be used only by SIP UAs that require outbound service. old SIP UAs as well as proxies would keep on querying the old service types. > So let's assume that DNS has been configured with both > _sip._proto.domain and _sip_out._proto.domain SRV records. > What should the NAPTR query for domain in that case return > for e.g. "SIP+D2U" ? it would return only _sip._proto.domain SRV records. > - If it returns both _sip._proto.domain and _sip_out._proto.domain > then the same proxy servers might appear within the SRV records > twice. Not good. Further on the UAs wanting Outbound service > would need to discard _sip._proto.domain SRV records before > sorting them as described in RFC 2782. Not nice either. i agree, not good. > - If it only returns _sip_out._proto.domain records then the > UAs expecting Outbound support would be happy. However if > there is any reason for an UA to try finding or using a proxy > without Outbound, then it turns out to be impossible with > NAPTR. This sounds too restrictive to me and would not allow > the use case outlined by Fredrik: > > > A real life example : I want people trying to reach my users > > to look up NAPTR/SRV for 'it.su.se' (naturally) but I want my > > clients to use other servers, currently indicated by NAPTR/SRV > > records for 'out.sip.su.se' because these other servers do > > stuff like Outbound, which the 'it.su.se' servers does not. yes, and this is solved by introducing new "O" NAPTR service types, which would only be queried by SIP UAs requiring outbound services. > So I would think, additionally to introducing the new type of > SRV records, the new NAPTR service types would anyway be necessary. yes, for those SIP UAs that do implement NAPTR lookups. > Then the question is, are those new types of SRV records _really_ > needed as they would add one extra piece of new specification, > complexity and source of errors for DNS configuration ? yes, IF we want to support SIP UAs that don't implement NAPTR lookups at all and do directly SRV lookups. so if such an UA requires outbound service, it would query _sip_out._proto.domain and if not it would query _sip._proto.domain SRV records. > Will implementing NAPTR support for those UAs be really so > much more difficult than implementing other new aspects > of Outbound (URN instance ID creation, STUN keepalives, > flow recovery, changes of DNS SRV record usage for using > backup proxies) so that there is no way for the Outbound > to rely on NAPTR ? that is what the WG needs to decide: do we make NAPTR lookup a MUST for SIP UAs implementing outbound I-D? a MUST would make SIP UA implementation more complex, but it would also make DNS provisioning more complex, because now EVERY domain would need to have both NAPTR and SRV records configured for it. -- 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 Mar 28 09:21:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOF2O-0006BJ-KI; Tue, 28 Mar 2006 09:19:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOF2N-0006BE-BL for sip@ietf.org; Tue, 28 Mar 2006 09:19:11 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOF2L-0004v0-M9 for sip@ietf.org; Tue, 28 Mar 2006 09:19:11 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 6E7ED194440 for ; Tue, 28 Mar 2006 16:19:08 +0200 (CEST) Received: from [192.168.1.15] ([192.168.1.15]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 16:17:24 +0200 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B1E7C83@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60B1E7C83@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <050c17118d98c59a95cf608c8b57180b@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] draft-ietf-sip-outbound Date: Tue, 28 Mar 2006 16:18:35 +0200 To: "Samir Srivastava" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 28 Mar 2006 14:17:24.0258 (UTC) FILETIME=[559A9020:01C65272] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sip@ietf.org, sip@ietf.orgList X-BeenThere: sip@ietf.org X-Mailman-Version: 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 asked the editors to add text advocating the choice of STUN over a SIP based mechanism and pointing out specific flaws in a sip based mechanism. They promised to do so. Hisham On Mar 28, 2006, at 3:47 AM, Samir Srivastava wrote: > I agree. But need concrete info where PING was bad. > > Thx > Samir > > -----Original Message----- > From: Audet, Francois [SC100:3055:EXCH] > Sent: Monday, March 27, 2006 3:07 PM > To: Dean Willis; Christer Holmberg ((JO/LMF)) > Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com > Subject: RE: [Sip] draft-ietf-sip-outbound > > Agree. > > The last meeting did indeed produce a strong rough consensus that the > way forward was STUN-over-SIP for both UDP and TCP. > > As one of the strongest proponent of the PING method, I think it is > time > to move on and and rally behind the concensus. The community will be > best served if we finalize sip-outbound rapidly. > > > > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Monday, March 27, 2006 14:56 >> To: Christer Holmberg ((JO/LMF)) >> Cc: sip@ietf.org; Drage, Keith (Keith); fwmiller@cornfed.com >> Subject: Re: [Sip] draft-ietf-sip-outbound >> >> >> >> On Mar 27, 2006, at 2:13 AM, Christer Holmberg ((JO/LMF)) wrote: >> >>> >>> Hi, >>> >>> I was not at the face-to-face meeting, but from the mail >> discussion I >>> haven't seen a sign of consensus. >> >> Having been the judge-of-consensus at the meeting, I noted about 185 >> hands in favor of STUN and about 5 holding out for PING. >> >> That's a pretty strong rough consensus. Admittedly, some of the more >> vocal PING proponents weren't present, but my sense of the matter is >> that the wider body of opinion does favor pursuing the >> standardization of the STUN approach. >> >> There was also a clear sense that the community wanted to document a >> single path rather than a set of alternatives. We've had a lot of >> folks recently airing frustrations about our usual tendency to >> document all proposed solutions to every problem and the rather >> horrible interoperability problem that approach might (or may >> already >> have) lead to. >> >> -- >> Dean Willis >> Chair, SIP working group >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current >> sip Use sipping@ietf.org for new developments on the >> application of sip >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 28 10:06:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOFkX-0001LN-8B; Tue, 28 Mar 2006 10:04:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOFkU-0001J6-2X for sip@ietf.org; Tue, 28 Mar 2006 10:04:46 -0500 Received: from ns1.sccx.com ([199.117.205.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOFkS-0006cb-Kc for sip@ietf.org; Tue, 28 Mar 2006 10:04:46 -0500 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] comments on location conveyance draft X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 28 Mar 2006 09:04:31 -0600 Message-ID: <422D410BD61FC04185076AD99AA7207A01772579@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZSBUGsDXT4ojZzQJa44qfFU+xxeQAcgEcg From: "McCalmont, Patti" To: "James M. Polk" , "Dale R. Worley" X-OriginalArrivalTime: 28 Mar 2006 15:04:33.0374 (UTC) FILETIME=[EBE367E0:01C65278] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: 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 James, I'm not opposed to moving this into the BCP but would like to see the following sentence re-written (last sentence before Section 7): "This capability MUST be configurable, but is not RECOMMENDED as the default configuration of any UA. Local policies will dictate this ability." Reword the "Local policies will dictate this ability." To "Local policies MUST be followed." Patti -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Monday, March 27, 2006 7:16 PM To: Dale R. Worley; McCalmont, Patti Cc: Sip; br@brianrosen.net Subject: RE: [Sip] comments on location conveyance draft Dale and Patti Brian Rosen and I are also writing the Emergency Phone BCP out of the ECRIT=20 WG. How about, in the interests of keeping most emergency related stuff in=20 ECRIT docs, that we make sure the Location Conveyance doc doesn't prevent=20 this disabling, and the Phone BCP makes this disabling strictly enforced like you want? This way your requirement is written where folks should know to look for emergency related features/functions, and we don't really cross WGs too much. I'm trying to maintain the balance I was told to maintain by one of the new=20 RAI Area Directors that was at the ECRIT interim meeting (you can guess=20 who) who reeeeeally wanted the Location doc to stay away from emergency=20 related issues as much as possible. This is one I believe we can directly=20 address in the Phone BCP doc to your liking. Is this a fair compromise? Or do you two still want this explicit in the Location doc? I also think we can add an informative reference in the location doc to the=20 phone BCP doc for a pointer of where other work around this can be found. At 12:35 PM 3/23/2006 -0500, Dale R. Worley wrote: >On Wed, 2006-03-22 at 19:30 -0600, McCalmont, Patti wrote: > > A UAC MUST be prevented from disabling conveyance of location for > > an emergency call if local jurisdiction (laws of that particular > > country) requires it. > >I think a requirement like this should be put into the draft. Not >because I think that necessarily every UAC should follow this rule -- >there are a host of complex issues here -- but because stating this as a >requirement will tend to cause UACs to be non-compliant only when >someone gave the issue serious consideration, instead of being non- >compliant because the implementer overlooked the issue. > >(I would rephrase the requirement something like this: "A UAC MUST >convey its location for an emergency call if it is required by the local >jurisdiction.") > >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 Tue Mar 28 11:13:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOGnb-0002jd-HG; Tue, 28 Mar 2006 11:12:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOGnZ-0002jY-Vf for sip@ietf.org; Tue, 28 Mar 2006 11:12:01 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOGnY-000129-OZ for sip@ietf.org; Tue, 28 Mar 2006 11:12:01 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.6/8.12.11) with ESMTP id k2SGBsVC036988; Tue, 28 Mar 2006 11:11:59 -0500 (EST) From: "Brett Tate" To: "'Elwell, John'" , "'Jonathan Rosenberg'" , "'IETF SIP List'" Subject: RE: [Sip] comments on sip-connected-identity Date: Tue, 28 Mar 2006 11:11:53 -0500 Message-ID: <004301c65282$54bc71e0$1d28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <50B1CBA96870A34799A506B2313F2667088028DD@ntht201e.siemenscomms.co.uk> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 am getting confused by this thread. In my opinion Jonathan=20 > clearly stated that UPDATE without SDP offer is allowed. Yes; he mentioned that it is allowed. However it wasn't clear to me and some others if Jonathan was indicating that UPDATE without SDP is valid = per rfc3311 or if the dialogURIChange tag is what allows it to be valid. = And since this is a common UPDATE interoperability problem, I was just = seeking clarity concerning his comment. The following is the snippet from http://www1.ietf.org/mail-archive/web/sip/current/msg13586.html. "Secondly, on the issue of UPDATE without offers, I believe it is fine = to do this. Though not in RFC3311, this was part of the original conceived use = of UPDATE (see = http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt). We decided towards the end of the development to focus on the session = update aspects of this. However, I think its fine to use UPDATE in this = fashion, as long as the peer in the dialog indicates support for this usage of = UPDATE (through the dialogURIChange tag)." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 28 11:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOGza-0001Ou-J5; Tue, 28 Mar 2006 11:24:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOGzZ-0001N9-T3 for sip@ietf.org; Tue, 28 Mar 2006 11:24:25 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOGzY-0001Vw-Gt for sip@ietf.org; Tue, 28 Mar 2006 11:24:25 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWU00A01IXKQM@siemenscomms.co.uk> for sip@ietf.org; Tue, 28 Mar 2006 17:24:56 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWU00A0JIXKQ9@siemenscomms.co.uk>; Tue, 28 Mar 2006 17:24:56 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Mar 2006 17:24:23 +0100 Content-return: allowed Date: Tue, 28 Mar 2006 17:24:05 +0100 From: "Elwell, John" Subject: RE: [Sip] comments on sip-connected-identity To: Brett Tate , 'Jonathan Rosenberg' , 'IETF SIP List' Message-id: <50B1CBA96870A34799A506B2313F266708852B3A@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Brett, OK, I understand. For this particular usage the dialogURIChange tag solves the problem anyway, regardless of whether it is allowed in more general circumstances. John > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: 28 March 2006 17:12 > To: Elwell, John; 'Jonathan Rosenberg'; 'IETF SIP List' > Subject: RE: [Sip] comments on sip-connected-identity > > > I am getting confused by this thread. In my opinion Jonathan > > clearly stated that UPDATE without SDP offer is allowed. > > Yes; he mentioned that it is allowed. However it wasn't > clear to me and > some others if Jonathan was indicating that UPDATE without > SDP is valid per > rfc3311 or if the dialogURIChange tag is what allows it to be > valid. And > since this is a common UPDATE interoperability problem, I was > just seeking > clarity concerning his comment. > > The following is the snippet from > http://www1.ietf.org/mail-archive/web/sip/current/msg13586.html. > > > "Secondly, on the issue of UPDATE without offers, I believe > it is fine to do > this. Though not in RFC3311, this was part of the original > conceived use of > UPDATE (see > http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt). > We decided towards the end of the development to focus on the > session update > aspects of this. However, I think its fine to use UPDATE in > this fashion, as > long as the peer in the dialog indicates support for this > usage of UPDATE > (through the dialogURIChange tag)." > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 28 13:47:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJC9-0006RW-By; Tue, 28 Mar 2006 13:45:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJC7-0006M3-Qs for sip@ietf.org; Tue, 28 Mar 2006 13:45:31 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJC6-0000YC-Kk for sip@ietf.org; Tue, 28 Mar 2006 13:45:31 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.6/8.12.11) with ESMTP id k2SIjQiY051623 for ; Tue, 28 Mar 2006 13:45:30 -0500 (EST) From: "Brett Tate" To: Subject: RE: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" Date: Tue, 28 Mar 2006 13:45:26 -0500 Message-ID: <000a01c65297$c775c000$1d28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F02201ECA@esebe103.NOE.Nokia.com> Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) 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 > Should NAPTR only have those good old services "SIPS+D2T",=20 > "SIP+D2T" and "SIP+D2U" or should the new "-O" services be=20 > introduced additionally to the new types of SRV records ? I have no strong preference. However this requires configuration of = extra records and requires the records to stay aligned concerning ports. If = the NAPTR records are good enough (and needed for indicating outbound = support), defining a new flag to indicate stun supported on this sip transport = target helps keep things aligned. And concerning the potential use of option tags within Require, = Supported, etcetera, I do not think they are adequate since they do not indicate = which device added it. Via header manipulation would likely work; however it introduces a = little extra processing overhead on the target. UAC adds Via parameter = "outbound". And when the proxy/UAS observes it and supports receiving stun on this port/connection, it adds a parameter like "outbound=3Dsupported" or "outbound=3Drequired". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 28 14:16:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJeJ-0000uR-0W; Tue, 28 Mar 2006 14:14:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJeI-0000u7-EC for sip@ietf.org; Tue, 28 Mar 2006 14:14:38 -0500 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 1FOJeI-0001dO-32 for sip@ietf.org; Tue, 28 Mar 2006 14:14:38 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 28 Mar 2006 11:14:37 -0800 X-IronPort-AV: i="4.03,139,1141632000"; d="scan'208"; a="317915356:sNHT32285340" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2SJEVwB004608; Tue, 28 Mar 2006 11:14:36 -0800 (PST) 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.211); Tue, 28 Mar 2006 11:14:35 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.20.4]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Mar 2006 11:14:34 -0800 Message-Id: <4.3.2.7.2.20060328131155.03333848@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Mar 2006 13:14:31 -0600 To: "McCalmont, Patti" , "Dale R. Worley" From: "James M. Polk" Subject: RE: [Sip] comments on location conveyance draft In-Reply-To: <422D410BD61FC04185076AD99AA7207A01772579@inilmx01.lgmt.trd o> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 Mar 2006 19:14:34.0476 (UTC) FILETIME=[D93DEAC0:01C6529B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: 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 At 09:04 AM 3/28/2006 -0600, McCalmont, Patti wrote: >James, > >I'm not opposed to moving this into the BCP but would like to see the >following sentence re-written (last sentence before Section 7): > >"This capability MUST be configurable, but is not RECOMMENDED as the >default configuration of any UA. Local policies will dictate this >ability." > >Reword the "Local policies will dictate this ability." > >To > >"Local policies MUST be followed." I'm ok with this. >Patti > > > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Monday, March 27, 2006 7:16 PM >To: Dale R. Worley; McCalmont, Patti >Cc: Sip; br@brianrosen.net >Subject: RE: [Sip] comments on location conveyance draft > >Dale and Patti > >Brian Rosen and I are also writing the Emergency Phone BCP out of the >ECRIT >WG. How about, in the interests of keeping most emergency related stuff >in >ECRIT docs, that we make sure the Location Conveyance doc doesn't >prevent >this disabling, and the Phone BCP makes this disabling strictly enforced > >like you want? > >This way your requirement is written where folks should know to look for > >emergency related features/functions, and we don't really cross WGs too >much. > >I'm trying to maintain the balance I was told to maintain by one of the >new >RAI Area Directors that was at the ECRIT interim meeting (you can guess >who) who reeeeeally wanted the Location doc to stay away from emergency >related issues as much as possible. This is one I believe we can >directly >address in the Phone BCP doc to your liking. > >Is this a fair compromise? > >Or do you two still want this explicit in the Location doc? > >I also think we can add an informative reference in the location doc to >the >phone BCP doc for a pointer of where other work around this can be >found. > > >At 12:35 PM 3/23/2006 -0500, Dale R. Worley wrote: > >On Wed, 2006-03-22 at 19:30 -0600, McCalmont, Patti wrote: > > > A UAC MUST be prevented from disabling conveyance of location >for > > > an emergency call if local jurisdiction (laws of that particular > > > country) requires it. > > > >I think a requirement like this should be put into the draft. Not > >because I think that necessarily every UAC should follow this rule -- > >there are a host of complex issues here -- but because stating this as >a > >requirement will tend to cause UACs to be non-compliant only when > >someone gave the issue serious consideration, instead of being non- > >compliant because the implementer overlooked the issue. > > > >(I would rephrase the requirement something like this: "A UAC MUST > >convey its location for an emergency call if it is required by the >local > >jurisdiction.") > > > >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 Tue Mar 28 14:58:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOKIh-0001q9-0l; Tue, 28 Mar 2006 14:56:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOKIe-0001pZ-Tg for sip@ietf.org; Tue, 28 Mar 2006 14:56:20 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOKId-00042J-Nn for sip@ietf.org; Tue, 28 Mar 2006 14:56:20 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.6/8.12.11) with ESMTP id k2SJuFO7058389 for ; Tue, 28 Mar 2006 14:56:19 -0500 (EST) From: "Brett Tate" To: Subject: RE: [Sip] draft-ietf-sip-outbound Date: Tue, 28 Mar 2006 14:56:15 -0500 Message-ID: <000d01c652a1$ac2c3b30$1d28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Having been the judge-of-consensus at the meeting,=20 > I noted about 185 hands in favor of STUN and=20 > about 5 holding out for PING. And at least 2 for double CRLF on TCP. :) > We've had a lot of folks recently airing frustrations=20 > about our usual tendency to document all proposed=20 > solutions to every problem and the rather horrible=20 > interoperability problem that approach might (or may=20 > already have) lead to. This seems like a good reason for this (or another) draft to discuss the alternative solutions for use until the STUN solution is supported by = both devices. Since the draft is basically silent, vendors will just = fallback to flooding the network with their favorite SIP request (REGISTERs, = etcetera) for solving the problem without much guidance or potential = optimizations. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 28 15:40:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOKxJ-00029W-GX; Tue, 28 Mar 2006 15:38:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOKxH-00029R-LA for sip@ietf.org; Tue, 28 Mar 2006 15:38:19 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOKxG-0005sl-9r for sip@ietf.org; Tue, 28 Mar 2006 15:38:19 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2SKcFf12854 for ; Tue, 28 Mar 2006 15:38:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-outbound Date: Tue, 28 Mar 2006 14:38:01 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B264F82@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZSoeU2Vabs6ivaQEWKJb4eVW7RXQAA2VVg From: "Samir Srivastava" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 This seems like a good reason for this (or another) draft to discuss the alternative solutions for use until the STUN solution is supported by both devices. Since the draft is basically silent, vendors will just fallback to flooding the network with their favorite SIP request (REGISTERs, etcetera) for solving the problem without much guidance or potential optimizations. SS>> I agree. =20 I captured following from SIPIT-16 (Apr 05) report. I couldn't find SIPIT-17 report from archive. Can somebody update on outbound from that. "There were 10 teams with implementations doing various things to keep NAT bindings alive (sending CRLFs, empty media packets, etc). The remainder were not attempting to address the problem at this time." There are *Empty Media Packets* too !! Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 28 19:51:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOOsX-0008OJ-87; Tue, 28 Mar 2006 19:49:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOOsW-0008OE-Bf for sip@ietf.org; Tue, 28 Mar 2006 19:49:40 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOOsV-0007t7-1H for sip@ietf.org; Tue, 28 Mar 2006 19:49:40 -0500 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2T0o7jV003376 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 28 Mar 2006 18:50:08 -0600 In-Reply-To: <000d01c652a1$ac2c3b30$1d28a8c0@brett1> References: <000d01c652a1$ac2c3b30$1d28a8c0@brett1> Mime-Version: 1.0 (Apple Message framework v746.3) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sip-outbound Date: Tue, 28 Mar 2006 18:49:55 -0600 To: Brett Tate X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Mar 28, 2006, at 1:56 PM, Brett Tate wrote: >> Having been the judge-of-consensus at the meeting, >> I noted about 185 hands in favor of STUN and >> about 5 holding out for PING. > > And at least 2 for double CRLF on TCP. :) > I stand corrected ;-) >> We've had a lot of folks recently airing frustrations >> about our usual tendency to document all proposed >> solutions to every problem and the rather horrible >> interoperability problem that approach might (or may >> already have) lead to. > > This seems like a good reason for this (or another) draft to > discuss the > alternative solutions for use until the STUN solution is supported > by both > devices. Since the draft is basically silent, vendors will just > fallback to > flooding the network with their favorite SIP request (REGISTERs, > etcetera) > for solving the problem without much guidance or potential > optimizations. That would seem to be reasonably in the scope of the SIPPING WG as a "BCP For SIP Keepalive In The Absence of STUN" or something like that. Could go into the Outbound draft, but it doesn't really need to, and it's likely to leave the historical record muddy if merged. -- 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 Mar 28 20:15:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOPFJ-0005DH-63; Tue, 28 Mar 2006 20:13:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOPFH-0005Af-3z for sip@ietf.org; Tue, 28 Mar 2006 20:13:11 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOPFF-0000Sk-Rx for sip@ietf.org; Tue, 28 Mar 2006 20:13:11 -0500 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 k2T1CxN01246; Tue, 28 Mar 2006 20:12:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on sip-connected-identity Date: Tue, 28 Mar 2006 19:12:57 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF08231727@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on sip-connected-identity Thread-Index: AcZSM7oGlNhwDMx8QiOJn95mAnEmtgAmZRLg From: "Francois Audet" To: "Elwell, John" , "Brett Tate" , "Christer Holmberg" , "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 RFC4028 (http://www.ietf.org/rfc/rfc4028.txt) describes the=20 use of UPDATEs without Offers (in this case it is for keep-alive). > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Monday, March 27, 2006 22:47 > To: Brett Tate; 'Christer Holmberg'; 'Jonathan Rosenberg';=20 > 'IETF SIP List' > Subject: RE: [Sip] comments on sip-connected-identity >=20 >=20 > Brett, >=20 > I am getting confused by this thread. In my opinion Jonathan=20 > clearly stated that UPDATE without SDP offer is allowed. >=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 Mar 28 20:15:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOPGC-0005pe-8U; Tue, 28 Mar 2006 20:14:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOPGB-0005pZ-3U for sip@ietf.org; Tue, 28 Mar 2006 20:14:07 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOPG9-0000Tx-RB for sip@ietf.org; Tue, 28 Mar 2006 20:14:07 -0500 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 k2T1DtN01291; Tue, 28 Mar 2006 20:13:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on sip-connected-identity Date: Tue, 28 Mar 2006 19:13:53 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0823172A@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on sip-connected-identity Thread-Index: AcZSM7oGlNhwDMx8QiOJn95mAnEmtgAmZRLgAAAp+FA= From: "Francois Audet" To: "Elwell, John" , "Brett Tate" , "Christer Holmberg" , "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 should have said "session refresh" instead of "keep-alive". > -----Original Message----- > From: Audet, Francois [SC100:3055:EXCH]=20 > Sent: Tuesday, March 28, 2006 17:13 > To: 'Elwell, John'; 'Brett Tate'; 'Christer Holmberg';=20 > 'Jonathan Rosenberg'; 'IETF SIP List' > Subject: RE: [Sip] comments on sip-connected-identity >=20 >=20 > RFC4028 (http://www.ietf.org/rfc/rfc4028.txt) describes the=20 > use of UPDATEs without Offers (in this case it is for keep-alive). >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Monday, March 27, 2006 22:47 > > To: Brett Tate; 'Christer Holmberg'; 'Jonathan Rosenberg';=20 > > 'IETF SIP List' > > Subject: RE: [Sip] comments on sip-connected-identity > >=20 > >=20 > > Brett, > >=20 > > I am getting confused by this thread. In my opinion Jonathan > > clearly stated that UPDATE without SDP offer is allowed. > >=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 Mar 28 21:24:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOQKo-0004Ct-C6; Tue, 28 Mar 2006 21:22:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOQKn-0004Co-4j for sip@ietf.org; Tue, 28 Mar 2006 21:22:57 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOQKl-0003fH-P3 for sip@ietf.org; Tue, 28 Mar 2006 21:22:57 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 988F86C01C for ; Tue, 28 Mar 2006 21:22:52 -0500 (EST) Subject: RE: [Sip] comments on location conveyance draft From: "Dale R. Worley" To: Sip In-Reply-To: <4.3.2.7.2.20060327190257.03349140@email.cisco.com> References: <422D410BD61FC04185076AD99AA7207A01771F16@inilmx01.lgmt.trdo> <422D410BD61FC04185076AD99AA7207A01771F16@inilmx01.lgmt.trdo> <4.3.2.7.2.20060327190257.03349140@email.cisco.com> Content-Type: text/plain Date: Tue, 28 Mar 2006 21:22:51 -0500 Message-Id: <1143598971.18974.4.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 On Mon, 2006-03-27 at 19:16 -0600, James M. Polk wrote: > Dale and Patti I don't have strong opinions on these subjects, and I'm sure that others who are directly involved can assess the value of my opinions better than I can... 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 Tue Mar 28 22:43:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FORZ2-0005Sj-E0; Tue, 28 Mar 2006 22:41:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FORZ0-0005Se-CR for sip@ietf.org; Tue, 28 Mar 2006 22:41:42 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FORYv-00068c-Hy for sip@ietf.org; Tue, 28 Mar 2006 22:41:42 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWV00LBKEMPZZ@szxga02-in.huawei.com> for sip@ietf.org; Wed, 29 Mar 2006 11:49:37 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWV00G29EMOWW@szxga02-in.huawei.com> for sip@ietf.org; Wed, 29 Mar 2006 11:49:37 +0800 (CST) Received: from w26552 ([10.76.176.31]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWV00LHNESF32@szxml01-in.huawei.com>; Wed, 29 Mar 2006 11:53:07 +0800 (CST) Date: Wed, 29 Mar 2006 11:36:00 +0800 From: Rocky Wang Subject: RE: [Sip] draft-cao-sip-response-identity-00.txt In-reply-to: <475FF955A05DD411980D00508B6D5FB0127491C6@en0033exch001u.uk.lucent.com> To: "'Drage, Keith (Keith)'" , sip@ietf.org Message-id: <000001c652e1$e5b9b4f0$1fb04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcZQ8e9f1Z71tVohSQWbmm2IN4BuLgB7wVJw X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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, As far as I considered, from the functinality and requirement = aspects, I feel it is useful to return back the responser idtifier as well. Is is possible to mrege the requirements of in both the drafts together? I = means only the requirements because I feel the solutions can be similar or the same. I think it is useful for implementers. Thanks, Rocky Wang > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: 2006=C4=EA3=D4=C227=C8=D5 0:25 > To: sip@ietf.org > Subject: [Sip] draft-cao-sip-response-identity-00.txt >=20 > (As chair) >=20 > At the face-to-face meeting at IETF #65 we discussed: >=20 > http://www.ietf.org/internet-drafts/draft-cao-sip-response-ide > ntity-00.txt >=20 > as a proposal for part of the solution to meeting the SIP=20 > milestone "Mechanism for Response Identity to IESG (PS) >=20 > A separate thread identifies another draft that forms part of=20 > this solution. >=20 > The face-to-face meeting reached no conclusion about whether=20 > this draft forms the basis for completing that milestone, or=20 > whether the problem cannot be resolved at all (or indeed that=20 > there is no support for a solution in this area) and=20 > therefore we should modify the existing milestone to remove=20 > response identity and leave only connected identity. >=20 > We would welcome proposals and comments to the list to=20 > resolve this issue one way or the other. >=20 > regards >=20 > Keith >=20 > Keith Drage > drage@lucent.com >=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 Mar 29 01:38:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOUHf-0003lz-PO; Wed, 29 Mar 2006 01:35:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOUGS-0002UC-Ns for sip@ietf.org; Wed, 29 Mar 2006 01:34:44 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOU5i-0003Qt-TF for sip@ietf.org; Wed, 29 Mar 2006 01:23:41 -0500 Received: (qmail 21748 invoked by uid 0); 29 Mar 2006 06:23:37 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 29 Mar 2006 06:23:37 -0000 Message-ID: <002601c652f9$4feb8fd0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Juha Heinanen" , References: <17448.55247.103128.728243@rautu.tutpro.com><8B1D53AEF7B03449A6D3771B3B7F850F02201ECA@esebe103.NOE.Nokia.com> <17449.16802.642384.111485@rautu.tutpro.com> Subject: Re: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" Date: Wed, 29 Mar 2006 08:23:36 +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.2670 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org, ft@it.su.se, 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 > > Will implementing NAPTR support for those UAs be really so > > much more difficult than implementing other new aspects > > of Outbound (URN instance ID creation, STUN keepalives, > > flow recovery, changes of DNS SRV record usage for using > > backup proxies) so that there is no way for the Outbound > > to rely on NAPTR ? > > that is what the WG needs to decide: do we make NAPTR lookup a MUST for > SIP UAs implementing outbound I-D? a MUST would make SIP UA > implementation more complex, but it would also make DNS provisioning > more complex, because now EVERY domain would need to have both NAPTR and > SRV records configured for it. > > -- juha To me this is all becoming way too heavy, and seems likely to introduce more problems than it solves The DNS discussion I have seen so far seems to assume that the outbound proxy is in the same domain as the home registrar. This is not always the case, in fact I expect that often it will ~not~ be the case. Therefore, local discovery mechanisms like DHCP and broadcast (as described in RFC3261) seem more appropriate to me. I understand the desire / requirement for automatic provisioning for specific (large scale) deployments, but this should not be mandated for everybody, IMHO I vote for a separate draft on this topic 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 Mar 29 02:23:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOUyz-0003Ev-3Y; Wed, 29 Mar 2006 02:20:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOUyp-00039l-OB for sip@ietf.org; Wed, 29 Mar 2006 02:20:35 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOUyl-0005iF-C5 for sip@ietf.org; Wed, 29 Mar 2006 02:20:35 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FOUyi-0000gP-J0; Wed, 29 Mar 2006 10:20:28 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17450.13628.479783.446624@harjus.tutpro.com> Date: Wed, 29 Mar 2006 10:20:28 +0300 To: "Jeroen van Bemmel" Subject: Re: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" In-Reply-To: <002601c652f9$4feb8fd0$31713b51@BEMBUSTER> References: <17448.55247.103128.728243@rautu.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F02201ECA@esebe103.NOE.Nokia.com> <17449.16802.642384.111485@rautu.tutpro.com> <002601c652f9$4feb8fd0$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org, ft@it.su.se, 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 Jeroen van Bemmel writes: > I understand the desire / requirement for > automatic provisioning for specific (large scale) deployments, but this > should not be mandated for everybody, IMHO i don't think anyone has proposed mandating to USE DNS discovery. it is just intended as the default Internet mode of operation that can be used when SIP UA can directly reach its home proxy/registrar. if your situation involves firewalls, SBCs or some other components whose operation is not defined by IETF, you can override the default mode of operation and use DHCP, manual configuration, TFTP or whatever. -- 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 Mar 29 02:49:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVON-0001wy-SD; Wed, 29 Mar 2006 02:46:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVOM-0001wh-7g for sip@ietf.org; Wed, 29 Mar 2006 02:46:58 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVOI-0006xv-OJ for sip@ietf.org; Wed, 29 Mar 2006 02:46:55 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2T7kbNK000337; Wed, 29 Mar 2006 10:46:41 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 10:45:51 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 10:45: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] How to indicate during proxy discovery thataproxysupports"outbound" Date: Wed, 29 Mar 2006 10:45:50 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0222F3CA@esebe103.NOE.Nokia.com> In-Reply-To: <002601c652f9$4feb8fd0$31713b51@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" Thread-Index: AcZS+W14zmcEDL+HRpWuSNCyhZLdYQACkQ4Q From: To: , X-OriginalArrivalTime: 29 Mar 2006 07:45:51.0723 (UTC) FILETIME=[CD5FF3B0:01C65304] X-Spam-Score: 0.2 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org, ft@it.su.se, 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 Jeroen, >The DNS discussion I have seen so far seems to assume=20 >that the outbound proxy is in the same domain as the=20 >home registrar. This is not always the case. >Therefore, local discovery mechanisms like DHCP and=20 >broadcast (as described in RFC3261) seem more=20 >appropriate to me. I believe you miss at least some of the point. The DNS procedure covers also the DHCP case. DHCP typically provides you the domain name of the SIP proxy like proxy.example.com. So what shall the UA do with that domain name, resolve it with DNS A query ?=20 Following RFC 3263 that is not the right answer since the domain name comes without port and transport information. The UA should do at first a NAPTR query for that domain and if it does not find any NAPTR records, then SRV queries for service and protocol it likes to use. A query is only the last resort if neither NAPTR or SRV records are available. So the DNS NAPTR and SRV procedures specifically cover also the DHCP case like I mentioned already earlier: - Would also support the case where domain name of the proxy is discovered by DHCP. As DHCP returns proxy domain names without port or transport, it causes the UA to make a NAPTR query for that domain, according to RFC 3263 >I vote for a separate draft on this topic Anyway since the proposed DNS procedures would impact the contents of RFC 3263 (new service types) a separate draft could be a reasonable approach. Regards, Erkki >-----Original Message----- >From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 >Sent: 29.March.2006 09:24 >To: Juha Heinanen; Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: sip@ietf.org; ft@it.su.se; dean.willis@softarmor.com >Subject: Re: [Sip] How to indicate during proxy discovery=20 >thataproxysupports"outbound" > >> > Will implementing NAPTR support for those UAs be really so >> > much more difficult than implementing other new aspects >> > of Outbound (URN instance ID creation, STUN keepalives, >> > flow recovery, changes of DNS SRV record usage for using >> > backup proxies) so that there is no way for the Outbound >> > to rely on NAPTR ? >> >> that is what the WG needs to decide: do we make NAPTR lookup=20 >a MUST for >> SIP UAs implementing outbound I-D? a MUST would make SIP UA >> implementation more complex, but it would also make DNS provisioning >> more complex, because now EVERY domain would need to have=20 >both NAPTR and >> SRV records configured for it. >> >> -- juha > >To me this is all becoming way too heavy, and seems likely to=20 >introduce more=20 >problems than it solves > >The DNS discussion I have seen so far seems to assume that the=20 >outbound=20 >proxy is in the same domain as the home registrar. This is not=20 >always the=20 >case, in fact I expect that often it will ~not~ be the case.=20 >Therefore,=20 >local discovery mechanisms like DHCP and broadcast (as=20 >described in RFC3261)=20 >seem more appropriate to me. I understand the desire / requirement for=20 >automatic provisioning for specific (large scale) deployments,=20 >but this=20 >should not be mandated for everybody, IMHO > >I vote for a separate draft on this topic > >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 Mar 29 02:54:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVTE-0005BI-MN; Wed, 29 Mar 2006 02:52:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVTD-0005BD-Mx for sip@ietf.org; Wed, 29 Mar 2006 02:51:59 -0500 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVTA-00075R-52 for sip@ietf.org; Wed, 29 Mar 2006 02:51:59 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 29 Mar 2006 08:51:54 +0100 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Mar 2006 09:51:54 +0200 Message-Id: From: "Jesske, R" To: john.elwell@siemens.com, rocky.wang@huawei.com, sip@ietf.org Subject: AW: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 Date: Wed, 29 Mar 2006 09:51:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 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 John, >However, there are some ambiguities in the PAI >RFC and past discussions on the list on this topic have led to the = opinion >from some experts that it is not intended for use in responses. I asked also on the list in the past and there was the said that the = PAI can be used within responses. As the RFC 3325 said that the PAI identifies the originator of an SIP = Message (Request/Response). Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > Gesendet: Donnerstag, 23. M=E4rz 2006 14:33 > An: Jesske, Roland; rocky.wang@huawei.com; sip@ietf.org > Betreff: RE: [Sip] draft-cao-sip-response-identity-00 and=20 > draft-elwell-sip -connected-identity-01 >=20 >=20 > Roland, >=20 > Yes, I agree that interworking with PSTN is not quite so=20 > straight forward > with this approach. Personally for networks where PAI is=20 > appropriate such as > TISPAN I see no objection to using it in a response, provided=20 > the asserting > entity has had some way of authenticating the connected UA=20 > (e.g., by virtue > of the response having been received on a TLS connection on=20 > which the UA has > already been authenticated). However, there are some=20 > ambiguities in the PAI > RFC and past discussions on the list on this topic have led=20 > to the opinion > from some experts that it is not intended for use in responses. >=20 > Note that Feng's proposal has the same limitation - an authentication > service cannot provide a cryptographic authentication of=20 > response identity > unless the UAS is reached by a TLS connection over which the=20 > UA has already > been authenticated. The connected-identity draft gets around=20 > this problem. >=20 > John=20 >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > > Sent: 23 March 2006 06:49 > > To: Elwell, John; rocky.wang@huawei.com; sip@ietf.org > > Subject: AW: [Sip] draft-cao-sip-response-identity-00 and=20 > > draft-elwell-sip -connected-identity-01 > >=20 > > Dear John, > > looking on your draft, I see the problem with the=20 > > interworking to the PSTN/ISDN network. > > With sending a 200OK in backward direction the PSTN Gateway=20 > > send an Answer in ISUP. So there is no chance to send an=20 > > second Answer because the call is already switched through. > > So in such a case new PSTN GWs are needed to wait until the=20 > > UPDATE is received. > >=20 > > You said that a Header is not secure. What we in TISPAN need=20 > > is a secure connected ID and a second from the user send=20 > > connected ID that must not be secure. > > Like as you indicate with your connected ID and the changed=20 > > From header. > >=20 > > Sorry for asking this question again > > Why can we not use the P-Asserted-Identity in Responses? It=20 > > is also a secure identity. > > And add only a new header like a connected-From header. Or is=20 > > this not generic enough? > >=20 > > Best Regards > >=20 > > Roland > >=20 > >=20 > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > > > Gesendet: Mittwoch, 22. M=E4rz 2006 19:45 > > > An: Rocky Wang; sip@ietf.org > > > Betreff: RE: [Sip] draft-cao-sip-response-identity-00 and=20 > > > draft-elwell-sip -connected-identity-01 > > >=20 > > >=20 > > > Rocky, > > >=20 > > > The connected-identity draft already gives two examples why a=20 > > > mid-dialog > > > change would be needed: PSTN gateway and B2BUA. > > >=20 > > > We could define a new header field for response identity if=20 > > > this can be > > > justified, but it would not be secure. I think the consensus=20 > > > yesterday was > > > to move forward with connected-identity and consider=20 > > > separately whether > > > response identity is achievable in a way that is secure as=20 > > > well as adding > > > some value in certain use cases. > > >=20 > > > John > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Rocky Wang [mailto:rocky.wang@huawei.com]=20 > > > > Sent: 22 March 2006 14:44 > > > > To: Elwell, John; sip@ietf.org > > > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and=20 > > > > draft-elwell-sip-connected-identity-01 > > > >=20 > > > > As my opinion, they two just need take the responser=20 > > > > identifier in the > > > > response messages. We must consider and resolve all the=20 > > > > problem include the > > > > security problems in both cases. > > > > If you want to indicate a change of party mid-dialog, you=20 > > > can use some > > > > mid-dialog method to do it, as I considered, just like UPDATE=20 > > > > and re-INVITE. > > > > That's not so difficult in use of exist mechanism. But can=20 > > > > you please give > > > > me an application case of the usage of mid-dialog entity=20 > > identifier > > > > indication. > > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > > > > Sent: Tuesday, March 21, 2006 11:44 PM > > > > To: Rocky Wang; sip@ietf.org > > > > Subject: RE: [Sip] draft-cao-sip-response-identity-00 and > > > > draft-elwell-sip-connected-identity-01 > > > >=20 > > > > Rocky, > > > >=20 > > > > The connected-identity draft is not a subset of the response=20 > > > > identity draft. > > > > The response identity draft cannot be used to indicate a=20 > > > > change of party > > > > mid-dialog. > > > >=20 > > > > I don't think we can merge them. There was no consensus on=20 > > > > the response > > > > identity draft. The following views have been expressed: > > > > - that it does not provide any benefit; > > > > - that the response identity problem cannot be solved, and=20 > > > > that the approach > > > > taken in the connected-identity draft is the best that can be=20 > > > > achieved. > > > >=20 > > > > If and when there is consensus on a response identity=20 > > > > solution, then we > > > > could consider whether it would be appropriate to merge the=20 > > > > two, but that is > > > > not the case at present. > > > >=20 > > > > John > > > >=20 > > > > > -----Original Message----- > > > > > From: Rocky Wang [mailto:rocky.wang@huawei.com] > > > > > Sent: 21 March 2006 19:50 > > > > > To: sip@ietf.org > > > > > Subject: [Sip] draft-cao-sip-response-identity-00 and > > > > > draft-elwell-sip-connected-identity-01 > > > > >=20 > > > > >=20 > > > > > Both of draft-cao-sip-response-identity-00 and > > > > > draft-elwell-sip-connected-identity-01 have been disscussed=20 > > > > in today's=20 > > > > > SIP session. I found they two can be merged into one. > > > > > The first one is a common requirement to return back=20 > > the identity=20 > > > > > identifier. It can be used in both successful responses,=20 > > > > but also in=20 > > > > > provisiional, redirect and failure responses, but the 2nd=20 > > > > one is just=20 > > > > > used for 18X and 2XX response for INVITE (maybe also some=20 > > > > other type=20 > > > > > requests). > > > > > As I considered, the 2nd one is just a sub-set case of the=20 > > > > first one.=20 > > > > > Can merge the 2nd one into the 1st one? Or merge the=20 > > > requirement of=20 > > > > > the 1st into the last. > > > > >=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=20 > > current sip Use=20 > > > > > sipping@ietf.org for new developments on the=20 > 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=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 Wed Mar 29 03:04:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVdc-00047l-Kg; Wed, 29 Mar 2006 03:02:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVdb-00046x-3i for sip@ietf.org; Wed, 29 Mar 2006 03:02:43 -0500 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVda-0007ZE-Mc for sip@ietf.org; Wed, 29 Mar 2006 03:02:43 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 29 Mar 2006 09:02:41 +0100 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Mar 2006 10:02:41 +0200 Message-Id: From: "Jesske, R" To: audet@nortel.com, john.elwell@siemens.com, brett@broadsoft.com, christer.holmberg@ericsson.com, jdrosen@cisco.com, sip@ietf.org Subject: AW: [Sip] comments on sip-connected-identity Date: Wed, 29 Mar 2006 10:02:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Sorry for bringing this again, why we have to use the UPDATE to get the = connected identities with the changed From and to header? This is = increasing SIP message flow for only sending a identity. There could be also other possibilities. Why not change the from in the 200 OK or define a new final Response like a 20X that is sent instead of the 200 = OK --> Problem are the existing implementations. Sending a 20x before a = 200 (20x no provisional response) or define a new provisional response that is only used to send the = regarding connected information (change of from header). Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Francois Audet [mailto:audet@nortel.com]=20 > Gesendet: Mittwoch, 29. M=E4rz 2006 03:14 > An: Elwell, John; Brett Tate; Christer Holmberg; Jonathan=20 > Rosenberg; IETF SIP List > Betreff: RE: [Sip] comments on sip-connected-identity >=20 >=20 > I should have said "session refresh" instead of "keep-alive". >=20 > > -----Original Message----- > > From: Audet, Francois [SC100:3055:EXCH]=20 > > Sent: Tuesday, March 28, 2006 17:13 > > To: 'Elwell, John'; 'Brett Tate'; 'Christer Holmberg';=20 > > 'Jonathan Rosenberg'; 'IETF SIP List' > > Subject: RE: [Sip] comments on sip-connected-identity > >=20 > >=20 > > RFC4028 (http://www.ietf.org/rfc/rfc4028.txt) describes the=20 > > use of UPDATEs without Offers (in this case it is for keep-alive). > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Monday, March 27, 2006 22:47 > > > To: Brett Tate; 'Christer Holmberg'; 'Jonathan Rosenberg';=20 > > > 'IETF SIP List' > > > Subject: RE: [Sip] comments on sip-connected-identity > > >=20 > > >=20 > > > Brett, > > >=20 > > > I am getting confused by this thread. In my opinion Jonathan > > > clearly stated that UPDATE without SDP offer is allowed. > > >=20 > > > John > > > > >=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 Mar 29 03:06:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVfK-0005wP-D2; Wed, 29 Mar 2006 03:04:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVfJ-0005wF-FT for sip@ietf.org; Wed, 29 Mar 2006 03:04:29 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVfI-0007eg-5c for sip@ietf.org; Wed, 29 Mar 2006 03:04:29 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FOVfH-0000ih-3I; Wed, 29 Mar 2006 11:04:27 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17450.16266.680016.430211@harjus.tutpro.com> Date: Wed, 29 Mar 2006 11:04:26 +0300 To: Fredrik Thulin Subject: Re: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" In-Reply-To: <200603290940.21446.ft@it.su.se> References: <17448.55247.103128.728243@rautu.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F02201ECA@esebe103.NOE.Nokia.com> <17449.16802.642384.111485@rautu.tutpro.com> <200603290940.21446.ft@it.su.se> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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 Fredrik Thulin writes: > In my opinion, Outbound does not need to take non-RFC3261/3263 compliant > UAs in consideration. fine with me, 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 Mar 29 03:21:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVu5-0006ey-EC; Wed, 29 Mar 2006 03:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVu4-0006et-9B for sip@ietf.org; Wed, 29 Mar 2006 03:19:44 -0500 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 1FOVu3-0008QI-Uk for sip@ietf.org; Wed, 29 Mar 2006 03:19:44 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A3140A90; Wed, 29 Mar 2006 03:19:32 -0500 From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" Subject: RE: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Wed, 29 Mar 2006 03:19:40 -0500 Message-ID: <01bd01c65309$87c036d0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZSLs+BZIsYIKD2Te2ltgA6ovaRYAA1YE5Q In-Reply-To: <002a01c6522e$cd4c9800$31713b51@BEMBUSTER> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org, '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 Jeroen, Comments inline... > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Tuesday, March 28, 2006 1:14 AM > > > But there are 3261 compliant proxies out there that don't support Path. > > So > > you will not know if the register went through one of those and hit an > > outbound registrar, vs. there was no proxy. I think a proxy-require is > > the > > only safe bet (and it would work across multiple proxies). It only > means > > an > > extra round-trip if it fails, and the truth is you do require the proxy > to > > support something, so why not use the header defined for that? > > If the outbound proxy does not support Path, it also does not support > outbound. In either case the UAC could detect this (i.e. no Path header > matching outbound proxy -> proxy does not support outbound). The problem > could be with proxies that ~do~ support Path, but for one reason or > another > do not wish to be in the path for inbound requests. On the other hand: > keepalive is only required for the path that inbound requests follow! Actually, I'm pretty sure keepalive is required for the first sip box the UA hits (the one outbound and inbound requests follow), because your nat-hole-flow is to it. I don't see how it's possible for your Register to go to a first proxy which is not in both the inbound and outbound request flow. How would the request get back through the nat-hole or TCP socket? More importantly, the local proxy could very well do Path but NOT support outbound. So you'll be doing it when you shouldn't. Second, it may be just a registrar without a proxy (no path header). So you won't be doing outbound when you should. (at least, I don't think a registrar supporting Path actually inserts it if it's an empty set, and it itself is not in the uri set) Fourth, if it's a proxy that does Path, there is no assurance the URI you get in the returned 200ok Path is its URI to you. Proxies can have multiple interfaces, and the Path URI will be the one pointing to the registrar, no? So you won't be doing outbound when you should. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 03:30:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOW33-0003D1-3y; Wed, 29 Mar 2006 03:29:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOW31-0003Cw-GJ for sip@ietf.org; Wed, 29 Mar 2006 03:28:59 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOW31-0000OO-7G for sip@ietf.org; Wed, 29 Mar 2006 03:28:59 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2T8SrZ14775; Wed, 29 Mar 2006 03:28:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-outbound Date: Wed, 29 Mar 2006 02:28:51 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B265575@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZTBF5kK002Rru7R1CUYm/khB2EbwABd1+Q From: "Samir Srivastava" To: "Hisham Khartabil" 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 My agreement was in documenting the alternatives and reasons for the chosen option.=20 Whether it is documented in SIPPING BCP or in outbound, I don't care. I care about the options documented somewhere.=20 Thx Samir=20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Tuesday, March 28, 2006 11:42 PM To: Srivastava, Samir [SC100:8826:EXCH] Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-outbound I don't agree. This is being done without documenting it. Once documented, it will never go away. We all know that. Hisham On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote: > > This seems like a good reason for this (or another) draft to discuss=20 > the alternative solutions for use until the STUN solution is supported > by both devices. Since the draft is basically silent, vendors will=20 > just fallback to flooding the network with their favorite SIP request=20 > (REGISTERs, etcetera) for solving the problem without much guidance or > potential optimizations. > > > SS>> I agree. > > I captured following from SIPIT-16 (Apr 05) report. I couldn't find > SIPIT-17 report from archive. Can somebody update on outbound from=20 > that. > > "There were 10 teams with implementations doing various things to keep > NAT bindings alive (sending CRLFs, empty media packets, etc). The=20 > remainder were not attempting to address the problem at this time." > > There are *Empty Media Packets* too !! > > > Thx > Samir > > > _______________________________________________ > 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 Wed Mar 29 03:36:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOW81-0005rt-Hj; Wed, 29 Mar 2006 03:34:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOW7z-0005qT-Ff for sip@ietf.org; Wed, 29 Mar 2006 03:34:07 -0500 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 1FOW7y-0000fA-4Q for sip@ietf.org; Wed, 29 Mar 2006 03:34:07 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A6750A80; Wed, 29 Mar 2006 03:33:57 -0500 From: "Hadriel Kaplan" To: "'Fredrik Thulin'" Subject: RE: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Wed, 29 Mar 2006 03:34:05 -0500 Message-ID: <01be01c6530b$8ad1f8c0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZSLgc8BncOMV+TTvCCMsZboE0DNgA3A0HQ In-Reply-To: <200603280808.12109.ft@it.su.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se] > Sent: Tuesday, March 28, 2006 1:08 AM > To: Hadriel Kaplan > > I don't give much for the 'let's just say every proxy needs to support > every extension'. If Outbound can be made to work with 'just' the edge > proxys and the proxys doing location service read/writes supporting > Outbound, then I think that is the right thing. Cool with me - that was all I was asking for. Checking the intermediates seemed like gravy to me, but one man's gravy is another man's dirty soup. Find a way that works every time and I'll shut up... about this topic. :) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 03:38:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOWAl-0000Pe-0E; Wed, 29 Mar 2006 03:36:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOWAk-0000P4-53 for sip@ietf.org; Wed, 29 Mar 2006 03:36:58 -0500 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 1FOWAj-0000ls-St for sip@ietf.org; Wed, 29 Mar 2006 03:36:58 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A7230A80; Wed, 29 Mar 2006 03:36:51 -0500 From: "Hadriel Kaplan" To: "'Bob Penfield'" , "'Fredrik Thulin'" , Subject: RE: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Date: Wed, 29 Mar 2006 03:37:00 -0500 Message-ID: <01bf01c6530b$f295ff60$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZSbnk02FK6CS19TMeYTBOJXkQASAANouJw In-Reply-To: <012601c6526e$7cf1cf20$800101df@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Hey Bob, Inline... > -----Original Message----- > From: Bob Penfield [mailto:BPenfield@acmepacket.com] > Sent: Tuesday, March 28, 2006 8:50 AM > To: Hadriel Kaplan; 'Fredrik Thulin'; sip@ietf.org > Subject: Re: [Sip] How to indicate during proxy discovery that > aproxysupports"outbound" > > > Actually, my impression is that P2 may have to support > > understanding outbound. The proxy forwarding rules changed > > in outbound. > > Intermediate proxies do not have to support outbound. The forwarding rules > have changed for the registrar/home-proxy and the edge proxy, not for > other > intermediate proxies. P2 would see a Route header pointing at P1. Yup - I was only referring to the case of P2 being the one doing location lookups. (his drawing only had P1 and P2 and a registrar, so that was a possibility in my paranoid interpretation) > > If P2 doesn't support outbound, and is the one > > doing location lookups, it may fork requests to the same UA > > through P1a and P1b to reach the UA. (not that that's a huge > > deal I guess, but it sounds bad to me that P2 could always > > be forking requests) > > If P2 is doing location lookups in the registrar (i.e. inbound requests go > to P2 rather than the registrar), then it qualifies as the home proxy and > would need to support outbound so that it would not fork the request. Exactly. But this draft-03, as written, does not stop the UA from performing outbound (and stun) even when the configuration flag is NOT set, and even when P2 does NOT indicate support for outbound. It's totally up to the UA. >From a protocol interop point of view, it's bizarre to me that the sender would be more liberal and the receiver would be less. (not from a security use of those words though) Is that an error in my interpretation/reading, or an error in the draft? I've read it a few times now and I can't seem to find anything stopping a UA from simply performing outbound (and sending STUN) at its own discretion, regardless of flags or supported: outbound responses. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 03:55:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOWR1-00018Y-Ht; Wed, 29 Mar 2006 03:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOWQz-00018T-R2 for sip@ietf.org; Wed, 29 Mar 2006 03:53:45 -0500 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 1FOWQy-0001Nr-B9 for sip@ietf.org; Wed, 29 Mar 2006 03:53:45 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id AB1209D4; Wed, 29 Mar 2006 03:53:38 -0500 From: "Hadriel Kaplan" To: "'Bob Penfield'" , "'Fredrik Thulin'" , Subject: RE: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Date: Wed, 29 Mar 2006 03:53:46 -0500 Message-ID: <01c701c6530e$4a62bbf0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZSbnk02FK6CS19TMeYTBOJXkQASAAnX04g In-Reply-To: <012601c6526e$7cf1cf20$800101df@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 > -----Original Message----- > From: Bob Penfield [mailto:BPenfield@acmepacket.com] > Sent: Tuesday, March 28, 2006 8:50 AM > To: Hadriel Kaplan; 'Fredrik Thulin'; sip@ietf.org > > [snipped] > > Again, only the "home proxy" (the one that does location lookup in the > registration data base), and the edge proxy (the one the UA has a direct > connection to) need to support the outbound draft and Path. Intermediate > proxies would see a Route header inserted by the home proxy on request > inbound to the UA. Besides, if the intervening proxy did not add a Path > header to the REGISTER, it probably would not even receive the inbound > request. Of course - but I can think of no other way, other than proxy-require and require, to be as sure as possible that the first edge sip box supports the new draft (and ergo STUN). Even a DNS-based SRV mechanism is flawed, simply because so many don't use SRV (and there's DHCP, et al). There has to also be an active check. One could have the sip-outbound compliant box actually _remove_ the proxy-require: outbound option-tag, which would only happen if it supported sip-outbound, and it could then forward the request on. And the sip-outbound compliant registrar is covered by the Require: option-tag idea. That way if the first box (proxy or registrar) wasn't sip-outbound, it would reject it. If the first box was sip-outbound compliant, the Register would get through a chain of any proxies and succeed (by not responding with a 420). At least that sounds right without thinking about it for too long, at 4am. :) But that would mean the first edge proxy would need to change from being a pure sip proxy... which now that I think about it, is exactly what the draft is already doing. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 04:35:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOX3Z-0000Lr-9x; Wed, 29 Mar 2006 04:33:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOX3Y-0000Lh-8U for sip@ietf.org; Wed, 29 Mar 2006 04:33:36 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVWQ-0007B5-6r for sip@ietf.org; Wed, 29 Mar 2006 02:55:18 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FOVK3-00088h-HE for sip@ietf.org; Wed, 29 Mar 2006 02:42:33 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 9EAC5194460 for ; Wed, 29 Mar 2006 09:42:29 +0200 (CEST) Received: from [192.168.1.18] ([192.168.1.18]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 09:40:44 +0200 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B264F82@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60B264F82@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] draft-ietf-sip-outbound Date: Wed, 29 Mar 2006 09:41:57 +0200 To: "Samir Srivastava" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 29 Mar 2006 07:40:44.0868 (UTC) FILETIME=[16799840:01C65304] X-Spam-Score: -2.6 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 don't agree. This is being done without documenting it. Once documented, it will never go away. We all know that. Hisham On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote: > > This seems like a good reason for this (or another) draft to discuss > the > alternative solutions for use until the STUN solution is supported by > both devices. Since the draft is basically silent, vendors will just > fallback to flooding the network with their favorite SIP request > (REGISTERs, etcetera) for solving the problem without much guidance or > potential optimizations. > > > SS>> I agree. > > I captured following from SIPIT-16 (Apr 05) report. I couldn't find > SIPIT-17 report from archive. Can somebody update on outbound from > that. > > "There were 10 teams with implementations doing various things to > keep NAT bindings alive (sending CRLFs, empty media packets, > etc). The remainder were not attempting to address the problem at > this time." > > There are *Empty Media Packets* too !! > > > Thx > Samir > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 04:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOXAy-0005Ft-VO; Wed, 29 Mar 2006 04:41:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOXAx-0005Fo-Q2 for sip@ietf.org; Wed, 29 Mar 2006 04:41:15 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVWQ-0007B5-Jm for sip@ietf.org; Wed, 29 Mar 2006 02:55:18 -0500 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FOVIb-000884-KR for sip@ietf.org; Wed, 29 Mar 2006 02:41:02 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 550DB3BF00; Wed, 29 Mar 2006 09:41:00 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30322-01-52; Wed, 29 Mar 2006 09:40:58 +0200 (CEST) Received: from dhcp-wavelan-v-37.publik.su.se (dhcp-wavelan-v-37.publik.su.se [193.10.145.37]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id C35AC3BEFD; Wed, 29 Mar 2006 09:40:54 +0200 (CEST) From: Fredrik Thulin To: Juha Heinanen Subject: Re: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Date: Wed, 29 Mar 2006 09:40:21 +0200 User-Agent: KMail/1.9.1 References: <17448.55247.103128.728243@rautu.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F02201ECA@esebe103.NOE.Nokia.com> <17449.16802.642384.111485@rautu.tutpro.com> In-Reply-To: <17449.16802.642384.111485@rautu.tutpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603290940.21446.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.665 tagged_above=-99 required=7 tests=[BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: -2.6 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 On Tuesday 28 March 2006 16:01, Juha Heinanen wrote: ... > > Will implementing NAPTR support for those UAs be really so > > much more difficult than implementing other new aspects > > of Outbound (URN instance ID creation, STUN keepalives, > > flow recovery, changes of DNS SRV record usage for using > > backup proxies) so that there is no way for the Outbound > > to rely on NAPTR ? > > that is what the WG needs to decide: do we make NAPTR lookup a MUST > for SIP UAs implementing outbound I-D? a MUST would make SIP UA > implementation more complex, but it would also make DNS provisioning > more complex, because now EVERY domain would need to have both NAPTR > and SRV records configured for it. I don't get this. UAs should have implemented NAPTR resolving years ago, when they started being RFC3261/3263 compliant, right? It's the SRV records in every domain that should go away - they are the ones making the DNS provisioning complex. In my opinion, Outbound does not need to take non-RFC3261/3263 compliant UAs in consideration. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 04:44:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOXCd-0006Yo-DV; Wed, 29 Mar 2006 04:42:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOXCc-0006Y9-Dg for sip@ietf.org; Wed, 29 Mar 2006 04:42:58 -0500 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 1FOXCY-0004dj-3p for sip@ietf.org; Wed, 29 Mar 2006 04:42:58 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A69309D0; Wed, 29 Mar 2006 04:42:43 -0500 From: "Hadriel Kaplan" To: "'Brett Tate'" , Subject: RE: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Date: Wed, 29 Mar 2006 04:42:51 -0500 Message-ID: <01cc01c65315$26022050$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZSl90f4GT5RuBWQj6rvZVxQ9Wm7QAcrevA In-Reply-To: <000a01c65297$c775c000$1d28a8c0@brett1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Brett, > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Tuesday, March 28, 2006 1:45 PM > > And concerning the potential use of option tags within Require, Supported, > etcetera, I do not think they are adequate since they do not indicate > which > device added it. > > Via header manipulation would likely work; however it introduces a little > extra processing overhead on the target. UAC adds Via parameter > "outbound". > And when the proxy/UAS observes it and supports receiving stun on this > port/connection, it adds a parameter like "outbound=supported" or > "outbound=required". Oh, an excellent idea. It's slightly less secure than a proxy-require, but it's a test without a failure round-trip. And it's hardly much overhead compared to being the edge proxy or UA for outbound anyway. And it's potentially a re-usable concept for a future draft for a proxy-to-proxy keepalive check. The only down-side is etiquette requires you to send the text for the draft if other people agree. ;) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 06:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZ9B-0007Sx-2K; Wed, 29 Mar 2006 06:47:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZ9A-0007Sr-6N for sip@ietf.org; Wed, 29 Mar 2006 06:47:32 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOZ99-0000Ew-NG for sip@ietf.org; Wed, 29 Mar 2006 06:47:32 -0500 Received: from rly03b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly03b.srv.mailcontrol.com (MailControl) with ESMTP id k2TBlUX2006016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Mar 2006 12:47:30 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly03b.srv.mailcontrol.com (MailControl) id k2TBkqZh004790 for sip@ietf.org; Wed, 29 Mar 2006 12:46:52 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly03b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k2TBkqvC004775; Wed, 29 Mar 2006 12:46:52 +0100 (BST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] draft-ietf-sip-outbound Date: Wed, 29 Mar 2006 12:46:52 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE031189A7@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZTFCI4v9NfYjCuQkqVhklW6q28hwAEd5Pg From: "Chris Boulton" To: "Hisham Khartabil" , "Samir Srivastava" X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.66.1.113 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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'm with Hisham on this - this has been discussed at length and a choice has been made. I certainly don't see the need to add another draft - we have way too many to read as it is. I was also at the meeting and feel that such decisions should just be accepted (the consensus was overwhelming) - otherwise we will find ourselves stuck on the same old IETF roundabout. Chris. -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: 29 March 2006 08:42 To: Samir Srivastava Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-outbound I don't agree. This is being done without documenting it. Once=20 documented, it will never go away. We all know that. Hisham On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote: > > This seems like a good reason for this (or another) draft to discuss=20 > the > alternative solutions for use until the STUN solution is supported by > both devices. Since the draft is basically silent, vendors will just > fallback to flooding the network with their favorite SIP request > (REGISTERs, etcetera) for solving the problem without much guidance or > potential optimizations. > > > SS>> I agree. > > I captured following from SIPIT-16 (Apr 05) report. I couldn't find > SIPIT-17 report from archive. Can somebody update on outbound from > that. > > "There were 10 teams with implementations doing various things to > keep NAT bindings alive (sending CRLFs, empty media packets, > etc). The remainder were not attempting to address the problem at > this time." > > There are *Empty Media Packets* too !! > > > Thx > Samir > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 06:52:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZBp-0001Kd-NJ; Wed, 29 Mar 2006 06:50:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZBo-0001KY-Mt for sip@ietf.org; Wed, 29 Mar 2006 06:50:16 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOZBo-0000Kk-8O for sip@ietf.org; Wed, 29 Mar 2006 06:50:16 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWW00L010WNUX@siemenscomms.co.uk> for sip@ietf.org; Wed, 29 Mar 2006 12:50:48 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWW00K9K0WNDK@siemenscomms.co.uk>; Wed, 29 Mar 2006 12:50:47 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 29 Mar 2006 12:50:13 +0100 Content-return: allowed Date: Wed, 29 Mar 2006 12:49:52 +0100 From: "Elwell, John" Subject: RE: [Sip] comments on sip-connected-identity To: "Jesske, R" , audet@nortel.com, brett@broadsoft.com, christer.holmberg@ericsson.com, jdrosen@cisco.com, sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667088531E2@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Roland, Changing the From (or the To) URI in a response would undermine the = rules for transactions in SIP. It was stated during the SIP meeting at IETF65 = that we should not do this. So the alternative is to convey information in = some other header or body in the response. Feng Cao addresses this in his response identity draft, although that received some comments during = IETF65 and will need to be reworked. The problem always is whether the UAS can = be authenticated - as I have stated before, this is only if the request = has been delivered over a TLS connection over which the UA has already been authenticated. I suggest you collaborate with Feng if you want this, = but personally I am not convinced that an adequate solution will be found. In the meantime we have a simple solution using connected-identity, = which in any case is needed for other situations. John > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > Sent: 29 March 2006 09:03 > To: audet@nortel.com; Elwell, John; brett@broadsoft.com;=20 > christer.holmberg@ericsson.com; jdrosen@cisco.com; sip@ietf.org > Subject: AW: [Sip] comments on sip-connected-identity >=20 > Sorry for bringing this again, why we have to use the UPDATE=20 > to get the connected identities with the changed From and to=20 > header? This is increasing SIP message flow for only sending=20 > a identity. >=20 > There could be also other possibilities. >=20 > Why not change the from in the 200 OK >=20 > or >=20 > define a new final Response like a 20X that is sent instead=20 > of the 200 OK --> Problem are the existing implementations.=20 > Sending a 20x before a 200 (20x no provisional response) >=20 > or >=20 > define a new provisional response that is only used to send=20 > the regarding connected information (change of from header). >=20 > Best Regards >=20 > Roland >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Francois Audet [mailto:audet@nortel.com]=20 > > Gesendet: Mittwoch, 29. M=E4rz 2006 03:14 > > An: Elwell, John; Brett Tate; Christer Holmberg; Jonathan=20 > > Rosenberg; IETF SIP List > > Betreff: RE: [Sip] comments on sip-connected-identity > >=20 > >=20 > > I should have said "session refresh" instead of "keep-alive". > >=20 > > > -----Original Message----- > > > From: Audet, Francois [SC100:3055:EXCH]=20 > > > Sent: Tuesday, March 28, 2006 17:13 > > > To: 'Elwell, John'; 'Brett Tate'; 'Christer Holmberg';=20 > > > 'Jonathan Rosenberg'; 'IETF SIP List' > > > Subject: RE: [Sip] comments on sip-connected-identity > > >=20 > > >=20 > > > RFC4028 (http://www.ietf.org/rfc/rfc4028.txt) describes the=20 > > > use of UPDATEs without Offers (in this case it is for = keep-alive). > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: Monday, March 27, 2006 22:47 > > > > To: Brett Tate; 'Christer Holmberg'; 'Jonathan Rosenberg';=20 > > > > 'IETF SIP List' > > > > Subject: RE: [Sip] comments on sip-connected-identity > > > >=20 > > > >=20 > > > > Brett, > > > >=20 > > > > I am getting confused by this thread. In my opinion Jonathan > > > > clearly stated that UPDATE without SDP offer is allowed. > > > >=20 > > > > John > > > > > > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 29 07:03:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZMU-0000Be-4k; Wed, 29 Mar 2006 07:01:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZMS-0000BU-By for sip@ietf.org; Wed, 29 Mar 2006 07:01:16 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOZMR-0000f1-U2 for sip@ietf.org; Wed, 29 Mar 2006 07:01:16 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWW001011F0IZ@siemenscomms.co.uk> for sip@ietf.org; Wed, 29 Mar 2006 13:01:48 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWW0007I1F0W6@siemenscomms.co.uk>; Wed, 29 Mar 2006 13:01:48 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 29 Mar 2006 13:01:14 +0100 Content-return: allowed Date: Wed, 29 Mar 2006 13:01:12 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-ietf-sip-outbound To: Chris Boulton , Hisham Khartabil , Samir Srivastava Message-id: <50B1CBA96870A34799A506B2313F26670885320E@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT 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 Yes, the mailing list archives and meeting minutes will show the reasons. I don't see the need for yet another draft and endless discussion during its production. Don't we have enough work to do? Let's just move on and get outbound finished. John > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 29 March 2006 12:47 > To: Hisham Khartabil; Samir Srivastava > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-outbound > > I'm with Hisham on this - this has been discussed at length > and a choice > has been made. I certainly don't see the need to add another > draft - we > have way too many to read as it is. I was also at the > meeting and feel > that such decisions should just be accepted (the consensus was > overwhelming) - otherwise we will find ourselves stuck on the same old > IETF roundabout. > > Chris. > > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: 29 March 2006 08:42 > To: Samir Srivastava > Cc: sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-outbound > > I don't agree. This is being done without documenting it. Once > documented, it will never go away. We all know that. > > Hisham > > On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote: > > > > > This seems like a good reason for this (or another) draft > to discuss > > the > > alternative solutions for use until the STUN solution is > supported by > > both devices. Since the draft is basically silent, vendors > will just > > fallback to flooding the network with their favorite SIP request > > (REGISTERs, etcetera) for solving the problem without much > guidance or > > potential optimizations. > > > > > > SS>> I agree. > > > > I captured following from SIPIT-16 (Apr 05) report. I couldn't find > > SIPIT-17 report from archive. Can somebody update on outbound from > > that. > > > > "There were 10 teams with implementations doing various things to > > keep NAT bindings alive (sending CRLFs, empty media packets, > > etc). The remainder were not attempting to address the problem at > > this time." > > > > There are *Empty Media Packets* too !! > > > > > > Thx > > Samir > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > Information contained in this e-mail and any attachments are > intended for the use of the addressee only, and may contain > confidential information of Ubiquity Software Corporation. > All unauthorized use, disclosure or distribution is strictly > prohibited. If you are not the addressee, please notify the > sender immediately and destroy all copies of this email. > Unless otherwise expressly agreed in writing signed by an > officer of Ubiquity Software Corporation, nothing in this > communication shall be deemed to be legally binding. Thank you. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 07:11:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZUz-0005Ei-AD; Wed, 29 Mar 2006 07:10:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZUy-0005Ed-3g for sip@ietf.org; Wed, 29 Mar 2006 07:10:04 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOZUx-0000tB-Dd for sip@ietf.org; Wed, 29 Mar 2006 07:10:04 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BC7184F0001; Wed, 29 Mar 2006 14:10:02 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 14:10:02 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 14:10:02 +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-outbound Date: Wed, 29 Mar 2006 14:10:01 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1BFB@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZTKI+OThZFvNboQTOT9ZQUwuZU5AAAJYGQ From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Chris Boulton" , "Hisham Khartabil" , "Samir Srivastava" X-OriginalArrivalTime: 29 Mar 2006 12:10:02.0405 (UTC) FILETIME=[B51E1550:01C65329] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) 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 Hi, If the meeting report will show why this solution was chosen, compared to others, and the arguments/pros/cons that were presented for the different solutions, before people were asked to raise their hand for one of the solutions, I will be happy. If the meeting report will only say "There was a concensus for STUN" it won't help very much, and I am pretty sure questions will come up again in the future ("I have just read this RFC, and I wonder why I can't use instead."). Also, since the network initiated keep-alives obviously were not discussed (please correct me if I'm wrong), I wonder if it would be possible to add some text in the draft indicating it is "out of the scope of the document", it is "for future work", or whatever, because as far as I am aware the whole discussion/scope has been about UA initiaded keep-alives. Regards, Christer=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: 29. maaliskuuta 2006 15:01 To: Chris Boulton; Hisham Khartabil; Samir Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Yes, the mailing list archives and meeting minutes will show the reasons. I don't see the need for yet another draft and endless discussion during its production. Don't we have enough work to do? Let's just move on and get outbound finished.=20 John=20 > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 29 March 2006 12:47 > To: Hisham Khartabil; Samir Srivastava > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-outbound >=20 > I'm with Hisham on this - this has been discussed at length and a=20 > choice has been made. I certainly don't see the need to add another=20 > draft - we have way too many to read as it is. I was also at the=20 > meeting and feel that such decisions should just be accepted (the=20 > consensus was > overwhelming) - otherwise we will find ourselves stuck on the same old > IETF roundabout. >=20 > Chris. >=20 >=20 > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: 29 March 2006 08:42 > To: Samir Srivastava > Cc: sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-outbound >=20 > I don't agree. This is being done without documenting it. Once=20 > documented, it will never go away. We all know that. >=20 > Hisham >=20 > On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote: >=20 > > > > This seems like a good reason for this (or another) draft > to discuss > > the > > alternative solutions for use until the STUN solution is > supported by > > both devices. Since the draft is basically silent, vendors > will just > > fallback to flooding the network with their favorite SIP request=20 > > (REGISTERs, etcetera) for solving the problem without much > guidance or > > potential optimizations. > > > > > > SS>> I agree. > > > > I captured following from SIPIT-16 (Apr 05) report. I couldn't find > > SIPIT-17 report from archive. Can somebody update on outbound from=20 > > that. > > > > "There were 10 teams with implementations doing various things to=20 > > keep NAT bindings alive (sending CRLFs, empty media packets, etc).=20 > > The remainder were not attempting to address the problem at this=20 > > time." > > > > There are *Empty Media Packets* too !! > > > > > > Thx > > Samir > > > > > > _______________________________________________ > > 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 > > >=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 > Information contained in this e-mail and any attachments are intended=20 > for the use of the addressee only, and may contain confidential=20 > information of Ubiquity Software Corporation. > All unauthorized use, disclosure or distribution is strictly=20 > prohibited. If you are not the addressee, please notify the sender=20 > immediately and destroy all copies of this email. > Unless otherwise expressly agreed in writing signed by an officer of=20 > Ubiquity Software Corporation, nothing in this communication shall be=20 > deemed to be legally binding. Thank you. >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 07:23:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZfl-0002Ja-6I; Wed, 29 Mar 2006 07:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZfj-0002JV-UM for sip@ietf.org; Wed, 29 Mar 2006 07:21:11 -0500 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOZfi-0001I9-H0 for sip@ietf.org; Wed, 29 Mar 2006 07:21:11 -0500 Received: from localhost (localhost [127.0.0.1]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP id 8385E10288; Wed, 29 Mar 2006 14:21:08 +0200 (CEST) Received: from [172.22.0.51] (tmg51.tmg.loc [172.22.0.51]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP; Wed, 29 Mar 2006 14:21:08 +0200 (CEST) Message-ID: <442A7BB4.3030505@cs.uni-goettingen.de> Date: Wed, 29 Mar 2006 14:21:08 +0200 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Keith (Keith)" , sip@ietf.org Subject: Re: [Sip] draft-tschofenig-sip-saml-05.txt References: <5EB80D22825EEE42872083AD5BFFB5945D1BFB@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1BFB@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by sophie+clamav (Debian) at informatik.uni-goettingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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, I think this draft is in a fairly good shape and would hum for it. (Actually a student of mine is working on a prototype implementation of it and hopefully some initial output will be available in a few months.) Cheers, Xiaoming -----Original Message----- From: Drage, Keith (Keith) [mailto:drage at lucent.com] Sent: Sunday, March 26, 2006 8:25 AM To: sip at ietf.org Subject: [Sip] draft-tschofenig-sip-saml-05.txt (As chair) At the face-to-face meeting at IETF#65, we discussed http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt as a possible solution to the current milestone on "Using SAML for SIP (PS)". We are seeking a list hum on whether this draft should be adopted as baseline for this draft, or whether we should seek some other baseline input. 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 Mar 29 08:29:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOaiF-00020A-Aj; Wed, 29 Mar 2006 08:27:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOaiD-000200-F1 for sip@ietf.org; Wed, 29 Mar 2006 08:27:49 -0500 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOaiD-0004NI-1r for sip@ietf.org; Wed, 29 Mar 2006 08:27:49 -0500 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 08F08210089; Wed, 29 Mar 2006 15:27:48 +0200 (CEST) Message-ID: <442A8BD0.2050303@pernau.at> Date: Wed, 29 Mar 2006 15:29:52 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Fredrik Thulin Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt References: <8B1D53AEF7B03449A6D3771B3B7F850F021C87AE@esebe103.NOE.Nokia.com> <200603241606.06251.ft@it.su.se> In-Reply-To: <200603241606.06251.ft@it.su.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sip@ietf.org, jh@tutpro.com, christer.holmberg@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 Fredrik Thulin wrote: > On Friday 24 March 2006 14:14, Erkki.Koivusalo@nokia.com wrote: > ... >> - Specify a way to derive from the host part of AOR two different >> names to resolve with DNS e.g. using a predefined prefix or postfix >> to the original domain name to indicate SRV entries for backup >> servers. > > I think this is the way to go for Outbound. The thing is that you might > very well want clients in your domain to connect to different SIP > servers than you want other domains trying to reach your users to > connect to. > > A real life example : I want people trying to reach my users to look up > NAPTR/SRV for 'it.su.se' (naturally) but I want my clients to use other > servers, currently indicated by NAPTR/SRV records for 'out.sip.su.se' > because these other servers do stuff like Outbound, which the > 'it.su.se' servers does not. This is a perfect example of the needs of current SIP installations. Probably a SIP service provider want to host different task on different machines, e.g: - A: one (or more) SIP proxy for signaling to other domains (which does TLS, SPIT detection ...) - B: one (or more) registrars/main proxy (which do client authentication, routing ...) - C: one (or more) proxies which perform NAT traversal (outbound/edge proxy) Thus, the same SIP AoR should resolve to different servers. E.g. sip:klaus@mydomain.com should resolve to proxies A if alice@atlanta.com (external domain) calls me. On the other hand, my SIP client, which is also configured with sip:klaus@mydomain.com should automatically resolve to proxies C. Taking a look at current implementations, some solve this proprietary. E.g. xlite utilizes SRV lookups for _outboundsip._udp.mydomain.com to detect the outbound proxies. Another example is Microsoft's LCS and the Live Communicator. The Live Communicator uses SRV lookups with _sipinternal._udp.mydomain.com to find the registrar whereas the LCS uses _sip.... to find other proxies. We need a mechanism for detecting the respective SIP proxy. From personal experiences, and the above examples prove that there is need for addressing different SIP proxies depending on the tasks. Using different SRV prefixes is one method. But it does not allow different transport preferences using NAPTR records for different proxy servers (e.g. if proxies A prefer TLS but proxies C prefer TCP). Of course these problems can be solved by complex configurations in the client. But here I have to second Juha: Configuring of a SIP client should only require AoR, username and password. regards Klaus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 08:31:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOajY-0002eg-0R; Wed, 29 Mar 2006 08:29:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOajW-0002eb-JJ for sip@ietf.org; Wed, 29 Mar 2006 08:29:10 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOajW-0004Ry-AH for sip@ietf.org; Wed, 29 Mar 2006 08:29:10 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2TDSwjR016899; Wed, 29 Mar 2006 07:28:59 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 29 Mar 2006 14:28:58 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012749578@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Rocky Wang'" , "'sip@ietf.org'" Subject: RE: [Sip] draft-cao-sip-response-identity-00.txt Date: Wed, 29 Mar 2006 14:28:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 chair) Currently we have agreement from the face-to-face meeting that the = concepts in connected identity are sufficiently well agreed to make it = into a deliverable from the working group. That is we have a set of = solutions that address the requirements in this area. We are confirming = that decision on the mailing list. For draft-cao-sip-response-identity-00.txt we currently have no = consensus about the mechanisms in the draft at all. What we heard in = the face-to-face meeting was cpnsiderable disagreement about whether = some of the requirements could be solved at all. We need to achieve = that consensus before we can agree that this should be either a = separate WG item or within an existing one. We do not plan to make any decision about the documentation of = draft-cao-sip-response-identity-00.txt until there is some consensus on = the mechanisms proposed and support for moving forward. At the moment = there have been no posts in favour or against achieving that consensus, = and at the moment all we can assume is that there is no support for = solving this problem at all.=20 regards Keith > -----Original Message----- > From: Rocky Wang [mailto:rocky.wang@huawei.com] > Sent: 29 March 2006 04:36 > To: 'Drage, Keith (Keith)'; sip@ietf.org > Subject: RE: [Sip] draft-cao-sip-response-identity-00.txt >=20 >=20 > Hi, Keith, > As far as I considered, from the functinality and=20 > requirement aspects, I > feel it is useful to return back the responser idtifier as well. Is = is > possible to mrege the requirements of in both the drafts=20 > together? I means > only the requirements because I feel the solutions can be=20 > similar or the > same. I think it is useful for implementers. >=20 > Thanks, > Rocky Wang >=20 >=20 > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > > Sent: 2006=C4=EA3=D4=C227=C8=D5 0:25 > > To: sip@ietf.org > > Subject: [Sip] draft-cao-sip-response-identity-00.txt > >=20 > > (As chair) > >=20 > > At the face-to-face meeting at IETF #65 we discussed: > >=20 > > http://www.ietf.org/internet-drafts/draft-cao-sip-response-ide > > ntity-00.txt > >=20 > > as a proposal for part of the solution to meeting the SIP=20 > > milestone "Mechanism for Response Identity to IESG (PS) > >=20 > > A separate thread identifies another draft that forms part of=20 > > this solution. > >=20 > > The face-to-face meeting reached no conclusion about whether=20 > > this draft forms the basis for completing that milestone, or=20 > > whether the problem cannot be resolved at all (or indeed that=20 > > there is no support for a solution in this area) and=20 > > therefore we should modify the existing milestone to remove=20 > > response identity and leave only connected identity. > >=20 > > We would welcome proposals and comments to the list to=20 > > resolve this issue one way or the other. > >=20 > > regards > >=20 > > Keith > >=20 > > Keith Drage > > drage@lucent.com > >=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 From sip-bounces@ietf.org Wed Mar 29 08:56:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOb82-0000I5-Aa; Wed, 29 Mar 2006 08:54:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOb80-0000Hs-VD for sip@ietf.org; Wed, 29 Mar 2006 08:54:28 -0500 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOb80-0005T1-Lk for sip@ietf.org; Wed, 29 Mar 2006 08:54:28 -0500 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 1AB53210089; Wed, 29 Mar 2006 15:54:28 +0200 (CEST) Message-ID: <442A9210.50506@pernau.at> Date: Wed, 29 Mar 2006 15:56:32 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt References: <17443.34205.560550.825661@harjus.tutpro.com> <500994B4-BB9F-4075-B95A-E7505B51658C@softarmor.com> <17444.5022.559809.34934@rautu.tutpro.com> <70E5D965-7AF7-4FD7-B6F6-3AB13AF4CA28@softarmor.com> <44241E2C.2030709@nokia.com> In-Reply-To: <44241E2C.2030709@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, Juha Heinanen , ext 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 Aki Niemi wrote: > > ext Dean Willis wrote: >> Possible alternatives: >> >> 1) Deducing from the proxy URL that it supports Outbound. This >> potentially works with DNS, DHCP, and configured discovery, but might >> just be a little too weird with our existing syntax and conventions. >> >> 2) Using a different service record in DNS, which works for DNS but not >> DHCP or configured use cases, I think. If there is a local outbound proxy required and configured by DHCP, the client can use this proxy. Further, this proxy could use DNS based methods to find out if the service provider also provides an edge proxy. regards klaus >> We have any other techniques that have been proposed here that I have >> missed? > > 3) The proxy corresponding to the entry in the SRV record of a domain, > inspects the Supported of an incoming request for the "outbound" token, > and if it exists, redirects the request either with a new 3xx "connect > to all of these", or use 300 with new bits that indicate this new semantic. > > 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 From sip-bounces@ietf.org Wed Mar 29 10:24:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOcVU-0006vr-Nj; Wed, 29 Mar 2006 10:22:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOcVR-0006v2-W1 for sip@ietf.org; Wed, 29 Mar 2006 10:22:46 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOcVR-0001Gj-M3 for sip@ietf.org; Wed, 29 Mar 2006 10:22:45 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2TFMiMt004378 for ; Wed, 29 Mar 2006 09:22:44 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k2TFMhj07138; Wed, 29 Mar 2006 09:22:43 -0600 (CST) Message-ID: <442AA643.3050904@lucent.com> Date: Wed, 29 Mar 2006 09:22:43 -0600 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] draft-cao-sip-response-identity-00.txt References: <475FF955A05DD411980D00508B6D5FB012749578@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB012749578@en0033exch001u.uk.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df 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="===============0048106541==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0048106541== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050502020200010300070102" This is a cryptographically signed message in MIME format. --------------ms050502020200010300070102 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > (as chair) [...] > We do not plan to make any decision about the documentation of > draft-cao-sip-response-identity-00.txt until there is some consensus > on the mechanisms proposed and support for moving forward. At the > moment there have been no posts in favour or against achieving that > consensus, and at the moment all we can assume is that there is no > support for solving this problem at all. Keith: Is it conceivable to break the milestone into two? One provides solution for knowing who I have connected with (connected-identity), and the other provides the identity of the intermediary or endpoint who issued provisional and non-2xx responses (could use response- identity as a starting point). I don't think there is much debate over connected-identity; the WG agrees that this is the way forward on knowing authoritatively who a UAC is connected to. connected-identity, IIRC, only kicks in when the UAS agrees to session establishment (i.e., a 200 OK is sent out). But what about user agents and intermediaries that issue non-2xx responses? Ostensibly, there could be some advantage in knowing that an intermediary who issued a 3xx is not sending me on a wild goose chase. TLS could be one way to ascertain the identity of the intermediary if I am connected directly (i.e., next hop) to the responder. But what about a chain of TLS proxies where the responding proxy or UAS is a few hops downstream? In that case, response-identity allows the receiver to know who issued a final response. So, does the WG see a need to provide a solution for response identity, which could be defined as the identity of an intermediary issuing a 1xx response or a non-2xx response, or the identity of an endpoint issuing a non-2xx response? If so, then maybe the following can be candidate proposals: 1) response-identity. 2) P-A-I applied to responses. 3) H-I header (I don't think this works since in H-I it is the UAC or the proxy that sends a request downstream that adds a H-I header. A UAS echoes the H-I headers, but does not add them pre-emptively, AFAIK). 4) Others...? Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms050502020200010300070102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjkxNTIyNDNaMCMGCSqGSIb3DQEJ BDEWBBSRCb5ZmLMpT3TCbgvf7SBGJ8G4VjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAsefqI6N0aFEPErozIf9biJIA+xw1qfzOUaBXWCRh+Ua/0Bd8Yy7a b9yx1u7Akd9U5+LPAEx1zs/DDfYL4QlJbwXf9LNnCxVAPaa9IOT7YU4Qc+XYRjyMMxnGiODC bFHJo9SyiInCloQIOLS6w0L0dYGgwtN+NPzvsesn+a0ozAcAAAAAAAA= --------------ms050502020200010300070102-- --===============0048106541== 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 --===============0048106541==-- From sip-bounces@ietf.org Wed Mar 29 11:00:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOd3m-0004d2-PR; Wed, 29 Mar 2006 10:58:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOd3l-0004bg-70 for sip@ietf.org; Wed, 29 Mar 2006 10:58:13 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOd3j-000303-02 for sip@ietf.org; Wed, 29 Mar 2006 10:58:13 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.6/8.12.11) with ESMTP id k2TFw579030377; Wed, 29 Mar 2006 10:58:09 -0500 (EST) From: "Brett Tate" To: "'Francois Audet'" , "'Jonathan Rosenberg'" , "'IETF SIP List'" Subject: RE: [Sip] comments on sip-connected-identity Date: Wed, 29 Mar 2006 10:58:05 -0500 Message-ID: <000901c65349$9150afa0$1d28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0823172A@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-PMX-IsInternal: True 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 > I should have said "session refresh" instead of "keep-alive". I agree that it is valid. I just want to ensure that the working group is in agreement that it is valid per RFC3311 without the need of an option tag to indicate when it is valid. RFC4028 mentions nothing about "timer" needing to be supported at the uas for UPDATE without offer to be valid. The text corresponds to my understanding of RFC3311; UPDATE without offer is valid per RFC3311 without the need of an option tag to indicate when it is valid. Because Jonathan was the author and recently potentially suggested otherwise, hopefully he will provide more clarity concerning his email since this is a common interoperability problem. > > -----Original Message----- > > From: Audet, Francois [SC100:3055:EXCH] > > Sent: Tuesday, March 28, 2006 17:13 > > To: 'Elwell, John'; 'Brett Tate'; 'Christer Holmberg'; > > 'Jonathan Rosenberg'; 'IETF SIP List' > > Subject: RE: [Sip] comments on sip-connected-identity > > > > > > RFC4028 (http://www.ietf.org/rfc/rfc4028.txt) describes the > > use of UPDATEs without Offers (in this case it is for keep-alive). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 11:12:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdFY-0000qr-4H; Wed, 29 Mar 2006 11:10:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdFV-0000fD-OR for sip@ietf.org; Wed, 29 Mar 2006 11:10:21 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOdFV-00041U-N5 for sip@ietf.org; Wed, 29 Mar 2006 11:10:21 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55] helo=zrtps0kn.nortel.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FOd4Y-0002gx-5Y for sip@ietf.org; Wed, 29 Mar 2006 10:59:03 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2TFwuY20038; Wed, 29 Mar 2006 10:58:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-outbound Date: Wed, 29 Mar 2006 09:58:43 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710DA58130@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZTE/Qlm26Bb0GYSjuy+iKbG12FAAANWYLg From: "Brian Stucker" To: "Hisham Khartabil" , "Samir Srivastava" X-Spam-Score: -2.6 (--) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 agree with you Hisham. Even with it not documented it'll take awhile = to clear out; no sense in working against ourselves. Regards, Brian -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] Sent: Wednesday, March 29, 2006 1:42 AM To: Srivastava, Samir [SC100:8826:EXCH] Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-outbound I don't agree. This is being done without documenting it. Once=20 documented, it will never go away. We all know that. Hisham On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote: > > This seems like a good reason for this (or another) draft to discuss=20 > the > alternative solutions for use until the STUN solution is supported by > both devices. Since the draft is basically silent, vendors will just > fallback to flooding the network with their favorite SIP request > (REGISTERs, etcetera) for solving the problem without much guidance or > potential optimizations. > > > SS>> I agree. > > I captured following from SIPIT-16 (Apr 05) report. I couldn't find > SIPIT-17 report from archive. Can somebody update on outbound from > that. > > "There were 10 teams with implementations doing various things to > keep NAT bindings alive (sending CRLFs, empty media packets, > etc). The remainder were not attempting to address the problem at > this time." > > There are *Empty Media Packets* too !! > > > Thx > Samir > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 11:24:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdRU-0004LN-H5; Wed, 29 Mar 2006 11:22:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdRS-0004LI-Hy for sip@ietf.org; Wed, 29 Mar 2006 11:22:42 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOdRR-0004R4-Qv for sip@ietf.org; Wed, 29 Mar 2006 11:22:42 -0500 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 k2TGMUv06283; Wed, 29 Mar 2006 11:22:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] draft-ietf-sip-outbound Date: Wed, 29 Mar 2006 10:22:30 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF035D4DFA@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZTKI+OThZFvNboQTOT9ZQUwuZU5AAAJYGQAAi6dYQ= References: <5EB80D22825EEE42872083AD5BFFB5945D1BFB@esealmw113.eemea.ericsson.se> From: "Francois Audet" To: "Christer Holmberg \(JO/LMF\)" , "Elwell, John" , "Chris Boulton" , "Hisham Khartabil" , "Samir Srivastava" X-Spam-Score: 0.6 (/) X-Scan-Signature: 8de8c36679aaa17b008853e74231c885 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="===============1277490907==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1277490907== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6534C.F9DE3880" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6534C.F9DE3880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't understand why we need to do this. We've never done this before = in IETF that I can remember,=20 and it seems to me to bean undue burden on the editors. Being a bunch = of engineers, we risk arguing endlessly about the justification itself (like we did on the mailing = list for 12 months). Instead of "making it go away", this explanation will just bring us back = 12 months. If the vote had been really close, maybe, but it wasn't: it was me and = four others against 185. I'd rather we spend time issuing the draft, and finishing up the vast = number of drafts waiting in the queue. ---- Fran=E7ois AUDET, Nortel Networks mailto:audet@nortel.com -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: Wed 29-Mar-06 4:10 AM To: Elwell, John; Chris Boulton; Hisham Khartabil; Srivastava, Samir = [SC100:8826:EXCH] Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound =20 Hi, If the meeting report will show why this solution was chosen, compared to others, and the arguments/pros/cons that were presented for the different solutions, before people were asked to raise their hand for one of the solutions, I will be happy. If the meeting report will only say "There was a concensus for STUN" it won't help very much, and I am pretty sure questions will come up again in the future ("I have just read this RFC, and I wonder why I can't use instead."). Also, since the network initiated keep-alives obviously were not discussed (please correct me if I'm wrong), I wonder if it would be possible to add some text in the draft indicating it is "out of the scope of the document", it is "for future work", or whatever, because as far as I am aware the whole discussion/scope has been about UA initiaded keep-alives. Regards, Christer=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: 29. maaliskuuta 2006 15:01 To: Chris Boulton; Hisham Khartabil; Samir Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Yes, the mailing list archives and meeting minutes will show the reasons. I don't see the need for yet another draft and endless discussion during its production. Don't we have enough work to do? Let's just move on and get outbound finished.=20 John=20 > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 29 March 2006 12:47 > To: Hisham Khartabil; Samir Srivastava > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-outbound >=20 > I'm with Hisham on this - this has been discussed at length and a=20 > choice has been made. I certainly don't see the need to add another=20 > draft - we have way too many to read as it is. I was also at the=20 > meeting and feel that such decisions should just be accepted (the=20 > consensus was > overwhelming) - otherwise we will find ourselves stuck on the same old > IETF roundabout. >=20 > Chris. >=20 >=20 > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: 29 March 2006 08:42 > To: Samir Srivastava > Cc: sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-outbound >=20 > I don't agree. This is being done without documenting it. Once=20 > documented, it will never go away. We all know that. >=20 > Hisham >=20 > On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote: >=20 > > > > This seems like a good reason for this (or another) draft > to discuss > > the > > alternative solutions for use until the STUN solution is > supported by > > both devices. Since the draft is basically silent, vendors > will just > > fallback to flooding the network with their favorite SIP request=20 > > (REGISTERs, etcetera) for solving the problem without much > guidance or > > potential optimizations. > > > > > > SS>> I agree. > > > > I captured following from SIPIT-16 (Apr 05) report. I couldn't find > > SIPIT-17 report from archive. Can somebody update on outbound from=20 > > that. > > > > "There were 10 teams with implementations doing various things to=20 > > keep NAT bindings alive (sending CRLFs, empty media packets, etc).=20 > > The remainder were not attempting to address the problem at this=20 > > time." > > > > There are *Empty Media Packets* too !! > > > > > > Thx > > Samir > > > > > > _______________________________________________ > > 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 > > >=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 > Information contained in this e-mail and any attachments are intended=20 > for the use of the addressee only, and may contain confidential=20 > information of Ubiquity Software Corporation. > All unauthorized use, disclosure or distribution is strictly=20 > prohibited. If you are not the addressee, please notify the sender=20 > immediately and destroy all copies of this email. > Unless otherwise expressly agreed in writing signed by an officer of=20 > Ubiquity Software Corporation, nothing in this communication shall be=20 > deemed to be legally binding. Thank you. >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C6534C.F9DE3880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-ietf-sip-outbound

I don't understand why we need to do this. We've never = done this before in IETF that I can remember,
and it seems to me to bean undue burden on the editors.  Being a = bunch of engineers, we risk arguing
endlessly about the justification itself (like we did on the mailing = list for 12 months).

Instead of "making it go away", this explanation will just = bring us back 12 months.

If the vote had been really close, maybe, but it wasn't: it was me and = four others against 185.

I'd rather we spend time issuing the draft, and finishing up the vast = number of drafts waiting in the
queue.

----
Fran=E7ois AUDET, Nortel Networks
mailto:audet@nortel.com



-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@e= ricsson.com]
Sent: Wed 29-Mar-06 4:10 AM
To: Elwell, John; Chris Boulton; Hisham Khartabil; Srivastava, Samir = [SC100:8826:EXCH]
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-outbound


Hi,

If the meeting report will show why this solution was chosen, = compared
to others, and the arguments/pros/cons that were presented for the
different solutions, before people were asked to raise their hand = for
one of the solutions, I will be happy.

If the meeting report will only say "There was a concensus for = STUN" it
won't help very much, and I am pretty sure questions will come up = again
in the future ("I have just read this RFC, and I wonder why I can't = use
<insert-your-favorite-method> instead.").

Also, since the network initiated keep-alives obviously were not
discussed (please correct me if I'm wrong), I wonder if it would be
possible to add some text in the draft indicating it is "out of = the
scope of the document", it is "for future work", or = whatever, because as
far as I am aware the whole discussion/scope has been about UA = initiaded
keep-alives.

Regards,

Christer



-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: 29. maaliskuuta 2006 15:01
To: Chris Boulton; Hisham Khartabil; Samir Srivastava
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-outbound

Yes, the mailing list archives and meeting minutes will show the
reasons. I don't see the need for yet another draft and endless
discussion during its production. Don't we have enough work to do? = Let's
just move on and get outbound finished.

John

> -----Original Message-----
> From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 29 March 2006 12:47
> To: Hisham Khartabil; Samir Srivastava
> Cc: sip@ietf.org
> Subject: RE: [Sip] draft-ietf-sip-outbound
>
> I'm with Hisham on this - this has been discussed at length and = a
> choice has been made.  I certainly don't see the need to add = another
> draft - we have way too many to read as it is.  I was also at = the
> meeting and feel that such decisions should just be accepted = (the
> consensus was
> overwhelming) - otherwise we will find ourselves stuck on the same = old

> IETF roundabout.
>
> Chris.
>
>
> -----Original Message-----
> From: Hisham Khartabil [mailto:hisham.khartabil@telio.n= o]
> Sent: 29 March 2006 08:42
> To: Samir Srivastava
> Cc: sip@ietf.org
> Subject: Re: [Sip] draft-ietf-sip-outbound
>
> I don't agree. This is being done without documenting it. Once
> documented, it will never go away. We all know that.
>
> Hisham
>
> On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote:
>
> >
> > This seems like a good reason for this (or another) draft
> to discuss
> > the
> > alternative solutions for use until the STUN solution is
> supported by
> > both devices.  Since the draft is basically silent, = vendors
> will just
> > fallback to flooding the network with their favorite SIP = request
> > (REGISTERs, etcetera) for solving the problem without much
> guidance or
> > potential optimizations.
> >
> >
> > SS>> I agree.
> >
> > I captured following from SIPIT-16 (Apr 05) report. I couldn't = find
> > SIPIT-17 report from archive.  Can somebody update on = outbound from
> > that.
> >
> > "There were 10 teams with implementations doing various = things to
> > keep NAT bindings alive (sending CRLFs, empty media packets, = etc).
> > The remainder were not attempting to address the problem at = this
> > time."
> >
> > There are *Empty Media Packets* too !!
> >
> >
> > Thx
> > Samir
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol = Use
> > sip-implementors@cs.columbia.edu for questions on current sip = Use
> > sipping@ietf.org for new developments on the application of = sip
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol = Use
> > sip-implementors@cs.columbia.edu for questions on current sip = Use
> > sipping@ietf.org for new developments on the application of = sip
> >
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> sip-implementors@cs.columbia.edu for questions on current sip = Use
> sipping@ietf.org for new developments on the application of sip
>
>
> Information contained in this e-mail and any attachments are = intended
> for the use of the addressee only, and may contain confidential
> information of Ubiquity Software Corporation.
> All unauthorized use, disclosure or distribution is strictly
> prohibited.  If you are not the addressee, please notify the = sender
> immediately and destroy all copies of this email.
> Unless otherwise expressly agreed in writing signed by an officer = of
> Ubiquity Software Corporation, nothing in this communication shall = be
> deemed to be legally binding.  Thank you.
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> sip-implementors@cs.columbia.edu for questions on current sip = Use
> sipping@ietf.org for new developments on the application of sip
>

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

_______________________________________________
Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This list is for NEW development of the core SIP 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_01C6534C.F9DE3880-- --===============1277490907== 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 --===============1277490907==-- From sip-bounces@ietf.org Wed Mar 29 11:57:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdx2-0002oF-Nc; Wed, 29 Mar 2006 11:55:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdx1-0002ne-76 for sip@ietf.org; Wed, 29 Mar 2006 11:55:19 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOdwz-00063r-L6 for sip@ietf.org; Wed, 29 Mar 2006 11:55:19 -0500 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 k2TGtEv18816 for ; Wed, 29 Mar 2006 11:55:14 -0500 (EST) Received: from [192.168.15.101] ([47.102.185.227] RDNS failed) by zrc2hxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 10:54:57 -0600 Message-ID: <442ABBE1.8050802@nortel.com> Date: Wed, 29 Mar 2006 08:54:57 -0800 From: "Francois Audet" Organization: Nortel Networks User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt References: <475FF955A05DD411980D00508B6D5FB012749578@en0033exch001u.uk.lucent.com> <442AA643.3050904@lucent.com> In-Reply-To: <442AA643.3050904@lucent.com> X-OriginalArrivalTime: 29 Mar 2006 16:54:57.0619 (UTC) FILETIME=[82A8BA30:01C65351] X-Spam-Score: 1.7 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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: , Content-Type: multipart/mixed; boundary="===============1642641270==" Errors-To: sip-bounces@ietf.org --===============1642641270== Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit My take is that there is no agreement that there is a compelling reason
to do response identity. That's the main issue.

I agree that connected-identity on the other is non-controversial.

Vijay K. Gurbani wrote: 
Drage, Keith (Keith) wrote:
  
(as chair)
    
[...]
  
We do not plan to make any decision about the documentation of
draft-cao-sip-response-identity-00.txt until there is some consensus
on the mechanisms proposed and support for moving forward. At the
moment there have been no posts in favour or against achieving that
consensus, and at the moment all we can assume is that there is no
support for solving this problem at all.
    

Keith: Is it conceivable to break the milestone into two?  One provides
solution for knowing who I have connected with (connected-identity),
and the other provides the identity of the intermediary or endpoint
who issued provisional and non-2xx responses (could use response-
identity as a starting point).

I don't think there is much debate over connected-identity; the WG
agrees that this is the way forward on knowing authoritatively
who a UAC is connected to.  connected-identity, IIRC, only kicks in
when the UAS agrees to session establishment (i.e., a 200 OK is sent
out).  But what about user agents and intermediaries that issue non-2xx
responses?

Ostensibly, there could be some advantage in knowing that an
intermediary who issued a 3xx is not sending me on a wild
goose chase.  TLS could be one way to ascertain the identity of the
intermediary if I am connected directly (i.e., next hop) to the
responder.  But what about a chain of TLS proxies where the responding
proxy or UAS is a few hops downstream?  In that case, response-identity
allows the receiver to know who issued a final response.

So, does the WG see a need to provide a solution for response identity,
which could be defined as the identity of an intermediary issuing a
1xx response or a non-2xx response, or the identity of an endpoint
issuing a non-2xx response?  If so, then maybe the following can be
candidate proposals:

1) response-identity.
2) P-A-I applied to responses.
3) H-I header (I don't think this works since in H-I it is the
   UAC or the proxy that sends a request downstream that adds a
   H-I header.  A UAS echoes the H-I headers, but does not add
   them pre-emptively, AFAIK).
4) Others...?

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

--===============1642641270== 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 --===============1642641270==-- From sip-bounces@ietf.org Wed Mar 29 12:55:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOer7-0001tb-V2; Wed, 29 Mar 2006 12:53:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOer7-0001tW-1f for sip@ietf.org; Wed, 29 Mar 2006 12:53:17 -0500 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 1FOer6-00005t-Ln for sip@ietf.org; Wed, 29 Mar 2006 12:53:17 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2006 09:53:16 -0800 X-IronPort-AV: i="4.03,144,1141632000"; d="scan'208"; a="421065623:sNHT44216116" 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 k2THrF7T025887; Wed, 29 Mar 2006 09:53:16 -0800 (PST) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 09:53:15 -0800 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] comments on sip-connected-identity Date: Wed, 29 Mar 2006 09:53:14 -0800 Message-ID: <5F16CF3DBBC7EE45BF6E136F13F5CFEA01E62870@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on sip-connected-identity Thread-Index: AcZTB3CBRsi3tyzNTD615zbfjt+4sQAUSY7Q From: "Feng Cao \(fcao\)" To: "Jesske, R" , , , , , "Jonathan Rosenberg \(jdrosen\)" , X-OriginalArrivalTime: 29 Mar 2006 17:53:15.0682 (UTC) FILETIME=[A7AAC820:01C65359] 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 The alternatives you brought up still need one mechanism to protect the = integrity of the connected-id. UPDATE leverages the identity work from = Jon and Cullen. That is the reason that this connected-id issue can be = easily covered by the identity work. Why not just insert response identity into response? This is more = generic and requires no additional response code ... =20 -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: Wednesday, March 29, 2006 12:03 AM To: audet@nortel.com; john.elwell@siemens.com; brett@broadsoft.com; = christer.holmberg@ericsson.com; Jonathan Rosenberg (jdrosen); = sip@ietf.org Subject: AW: [Sip] comments on sip-connected-identity Sorry for bringing this again, why we have to use the UPDATE to get the = connected identities with the changed From and to header? This is = increasing SIP message flow for only sending a identity. There could be also other possibilities. Why not change the from in the 200 OK or define a new final Response like a 20X that is sent instead of the 200 = OK --> Problem are the existing implementations. Sending a 20x before a = 200 (20x no provisional response) or define a new provisional response that is only used to send the = regarding connected information (change of from header). Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Francois Audet [mailto:audet@nortel.com] > Gesendet: Mittwoch, 29. M=E4rz 2006 03:14 > An: Elwell, John; Brett Tate; Christer Holmberg; Jonathan Rosenberg;=20 > IETF SIP List > Betreff: RE: [Sip] comments on sip-connected-identity >=20 >=20 > I should have said "session refresh" instead of "keep-alive". >=20 > > -----Original Message----- > > From: Audet, Francois [SC100:3055:EXCH] > > Sent: Tuesday, March 28, 2006 17:13 > > To: 'Elwell, John'; 'Brett Tate'; 'Christer Holmberg'; 'Jonathan=20 > > Rosenberg'; 'IETF SIP List' > > Subject: RE: [Sip] comments on sip-connected-identity > >=20 > >=20 > > RFC4028 (http://www.ietf.org/rfc/rfc4028.txt) describes the use of=20 > > UPDATEs without Offers (in this case it is for keep-alive). > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Monday, March 27, 2006 22:47 > > > To: Brett Tate; 'Christer Holmberg'; 'Jonathan Rosenberg'; 'IETF=20 > > > SIP List' > > > Subject: RE: [Sip] comments on sip-connected-identity > > >=20 > > >=20 > > > Brett, > > >=20 > > > I am getting confused by this thread. In my opinion Jonathan=20 > > > clearly stated that UPDATE without SDP offer is allowed. > > >=20 > > > John > > > > >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 13:06:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOf1y-0004t0-4T; Wed, 29 Mar 2006 13:04:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOf1x-0004su-1A for sip@ietf.org; Wed, 29 Mar 2006 13:04:29 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOf1v-0001Az-NP for sip@ietf.org; Wed, 29 Mar 2006 13:04:29 -0500 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2TI5003006899 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 29 Mar 2006 12:05:01 -0600 In-Reply-To: <442ABBE1.8050802@nortel.com> References: <475FF955A05DD411980D00508B6D5FB012749578@en0033exch001u.uk.lucent.com> <442AA643.3050904@lucent.com> <442ABBE1.8050802@nortel.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt Date: Wed, 29 Mar 2006 12:04:49 -0600 To: "Francois Audet" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "sip@ietf.org 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 On Mar 29, 2006, at 10:54 AM, Francois Audet wrote: > My take is that there is no agreement that there is a compelling > reason > to do response identity. That's the main issue. > > I agree that connected-identity on the other is non-controversial. I propose that we amend the charter to show a midsummer deliverable for connected identity, and use the Elwell draft as a basis for this deliverable. Then we add a later milestone to deliver a decision on whether we will be adding a new milestone for response identity. How does that sound? -- 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 Mar 29 13:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOf35-0005HT-4o; Wed, 29 Mar 2006 13:05:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOf33-0005Eh-Jj for sip@ietf.org; Wed, 29 Mar 2006 13:05:37 -0500 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 1FOf32-0001HT-OZ for sip@ietf.org; Wed, 29 Mar 2006 13:05:37 -0500 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id AC6A0264; Wed, 29 Mar 2006 13:05:30 -0500 From: "Hadriel Kaplan" To: Subject: RE: [Sip] draft-ietf-sip-outbound Date: Wed, 29 Mar 2006 13:05:39 -0500 Message-ID: <025801c6535b$62ce1480$6501a8c0@acmepacket.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZTKI+OThZFvNboQTOT9ZQUwuZU5AAAJYGQAAi6dYQAAp/bEA== In-Reply-To: <1ECE0EB50388174790F9694F77522CCF035D4DFA@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4ad60914b71abd47c285b3604f8c8304 X-BeenThere: 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="===============1897959139==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1897959139== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0259_01C65331.79F80C80" This is a multi-part message in MIME format. ------=_NextPart_000_0259_01C65331.79F80C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Explicitly documenting it also has the danger that:=20 (a) the issues are not represented accurately, or are biased in = their representation =96 so we end up arguing over how the arguments should = be presented, ad nauseam. (some people already feel this way about the = previous discussion, so I=92m not guessing on this) (b) someone may decide they prefer one of the other approaches = because of its documented characteristics, and can point to an IETF sip-wg = document as =93supporting material=94 =96 which would hurt one of the ultimate = goals: interoperability.=20 =20 So I, too, think it unwise. (and I was a guy who was in the anti-stun = camp, but unfortunately did not go to Dallas) =20 We need to move on and make the decision safe and practical to use.=20 =20 -hadriel =20 _____ =20 From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Wednesday, March 29, 2006 11:23 AM To: Christer Holmberg (JO/LMF); Elwell, John; Chris Boulton; Hisham Khartabil; Samir Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound =20 I don't understand why we need to do this. We've never done this before = in IETF that I can remember, and it seems to me to bean undue burden on the editors. Being a bunch = of engineers, we risk arguing endlessly about the justification itself (like we did on the mailing = list for 12 months). Instead of "making it go away", this explanation will just bring us back = 12 months. If the vote had been really close, maybe, but it wasn't: it was me and = four others against 185. I'd rather we spend time issuing the draft, and finishing up the vast = number of drafts waiting in the queue. ---- Fran=E7ois AUDET, Nortel Networks mailto:audet@nortel.com -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: Wed 29-Mar-06 4:10 AM To: Elwell, John; Chris Boulton; Hisham Khartabil; Srivastava, Samir [SC100:8826:EXCH] Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Hi, If the meeting report will show why this solution was chosen, compared to others, and the arguments/pros/cons that were presented for the different solutions, before people were asked to raise their hand for one of the solutions, I will be happy. If the meeting report will only say "There was a concensus for STUN" it won't help very much, and I am pretty sure questions will come up again in the future ("I have just read this RFC, and I wonder why I can't use instead."). Also, since the network initiated keep-alives obviously were not discussed (please correct me if I'm wrong), I wonder if it would be possible to add some text in the draft indicating it is "out of the scope of the document", it is "for future work", or whatever, because as far as I am aware the whole discussion/scope has been about UA initiaded keep-alives. Regards, Christer -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: 29. maaliskuuta 2006 15:01 To: Chris Boulton; Hisham Khartabil; Samir Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Yes, the mailing list archives and meeting minutes will show the reasons. I don't see the need for yet another draft and endless discussion during its production. Don't we have enough work to do? Let's just move on and get outbound finished. John > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 29 March 2006 12:47 > To: Hisham Khartabil; Samir Srivastava > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-outbound > > I'm with Hisham on this - this has been discussed at length and a > choice has been made. I certainly don't see the need to add another > draft - we have way too many to read as it is. I was also at the > meeting and feel that such decisions should just be accepted (the > consensus was > overwhelming) - otherwise we will find ourselves stuck on the same old > IETF roundabout. > > Chris. > > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: 29 March 2006 08:42 > To: Samir Srivastava > Cc: sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-outbound > > I don't agree. This is being done without documenting it. Once > documented, it will never go away. We all know that. > > Hisham > > On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote: > > > > > This seems like a good reason for this (or another) draft > to discuss > > the > > alternative solutions for use until the STUN solution is > supported by > > both devices. Since the draft is basically silent, vendors > will just > > fallback to flooding the network with their favorite SIP request > > (REGISTERs, etcetera) for solving the problem without much > guidance or > > potential optimizations. > > > > > > SS>> I agree. > > > > I captured following from SIPIT-16 (Apr 05) report. I couldn't find > > SIPIT-17 report from archive. Can somebody update on outbound from > > that. > > > > "There were 10 teams with implementations doing various things to > > keep NAT bindings alive (sending CRLFs, empty media packets, etc). > > The remainder were not attempting to address the problem at this > > time." > > > > There are *Empty Media Packets* too !! > > > > > > Thx > > Samir > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > Information contained in this e-mail and any attachments are intended > for the use of the addressee only, and may contain confidential > information of Ubiquity Software Corporation. > All unauthorized use, disclosure or distribution is strictly > prohibited. If you are not the addressee, please notify the sender > immediately and destroy all copies of this email. > Unless otherwise expressly agreed in writing signed by an officer of > Ubiquity Software Corporation, nothing in this communication shall be > deemed to be legally binding. Thank you. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_NextPart_000_0259_01C65331.79F80C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-ietf-sip-outbound

Explicitly documenting it also has = the danger that:

(a)     = the issues are not represented accurately, or are biased in = their representation =A0– so we end up arguing over how the arguments = should be presented, ad nauseam. (some people already feel this way about the = previous discussion, so I’m not guessing on = this)

(b)     = someone may decide they prefer one of the other approaches = because of its documented characteristics, and can point to an IETF sip-wg document = as “supporting material” – which would hurt one of the ultimate goals: interoperability.

 

So I, too, think it unwise. =A0(and = I was a guy who was in the anti-stun camp, but unfortunately did not go to = Dallas)

 

We need to move on and make the = decision safe and practical to use.

 

-hadriel

 

From: = Francois Audet [mailto:audet@nortel.com]
Sent: Wednesday, March = 29, 2006 11:23 AM
To: Christer Holmberg = (JO/LMF); Elwell, John; Chris Boulton; Hisham Khartabil; Samir Srivastava
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-outbound

 

I don't understand why we need to do this. = We've never done this before in IETF that I can remember,
and it seems to me to bean undue burden on the editors.  Being a = bunch of engineers, we risk arguing
endlessly about the justification itself (like we did on the mailing = list for 12 months).

Instead of "making it go away", this explanation will just = bring us back 12 months.

If the vote had been really close, maybe, but it wasn't: it was me and = four others against 185.

I'd rather we spend time issuing the draft, and finishing up the vast = number of drafts waiting in the
queue.

----
Fran=E7ois AUDET, Nortel Networks
mailto:audet@nortel.com



-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@e= ricsson.com]
Sent: Wed 29-Mar-06 4:10 AM
To: Elwell, John; Chris Boulton; Hisham Khartabil; Srivastava, Samir [SC100:8826:EXCH]
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-outbound


Hi,

If the meeting report will show why this solution was chosen, = compared
to others, and the arguments/pros/cons that were presented for the
different solutions, before people were asked to raise their hand = for
one of the solutions, I will be happy.

If the meeting report will only say "There was a concensus for = STUN" it
won't help very much, and I am pretty sure questions will come up = again
in the future ("I have just read this RFC, and I wonder why I can't = use
<insert-your-favorite-method> instead.").

Also, since the network initiated keep-alives obviously were not
discussed (please correct me if I'm wrong), I wonder if it would be
possible to add some text in the draft indicating it is "out of = the
scope of the document", it is "for future work", or = whatever, because as
far as I am aware the whole discussion/scope has been about UA = initiaded
keep-alives.

Regards,

Christer



-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: 29. maaliskuuta 2006 15:01
To: Chris Boulton; Hisham Khartabil; Samir Srivastava
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-outbound

Yes, the mailing list archives and meeting minutes will show the
reasons. I don't see the need for yet another draft and endless
discussion during its production. Don't we have enough work to do? = Let's
just move on and get outbound finished.

John

> -----Original Message-----
> From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 29 March 2006 12:47
> To: Hisham Khartabil; Samir Srivastava
> Cc: sip@ietf.org
> Subject: RE: [Sip] draft-ietf-sip-outbound
>
> I'm with Hisham on this - this has been discussed at length and = a
> choice has been made.  I certainly don't see the need to add = another
> draft - we have way too many to read as it is.  I was also at = the
> meeting and feel that such decisions should just be accepted = (the
> consensus was
> overwhelming) - otherwise we will find ourselves stuck on the same = old

> IETF roundabout.
>
> Chris.
>
>
> -----Original Message-----
> From: Hisham Khartabil [mailto:hisham.khartabil@telio.n= o]
> Sent: 29 March 2006 08:42
> To: Samir Srivastava
> Cc: sip@ietf.org
> Subject: Re: [Sip] draft-ietf-sip-outbound
>
> I don't agree. This is being done without documenting it. Once
> documented, it will never go away. We all know that.
>
> Hisham
>
> On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote:
>
> >
> > This seems like a good reason for this (or another) draft
> to discuss
> > the
> > alternative solutions for use until the STUN solution is
> supported by
> > both devices.  Since the draft is basically silent, = vendors
> will just
> > fallback to flooding the network with their favorite SIP = request
> > (REGISTERs, etcetera) for solving the problem without much
> guidance or
> > potential optimizations.
> >
> >
> > SS>> I agree.
> >
> > I captured following from SIPIT-16 (Apr 05) report. I couldn't = find
> > SIPIT-17 report from archive.  Can somebody update on = outbound from
> > that.
> >
> > "There were 10 teams with implementations doing various = things to
> > keep NAT bindings alive (sending CRLFs, empty media packets, = etc).
> > The remainder were not attempting to address the problem at = this
> > time."
> >
> > There are *Empty Media Packets* too !!
> >
> >
> > Thx
> > Samir
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol = Use
> > sip-implementors@cs.columbia.edu for questions on current sip = Use
> > sipping@ietf.org for new developments on the application of = sip
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol = Use
> > sip-implementors@cs.columbia.edu for questions on current sip = Use
> > sipping@ietf.org for new developments on the application of = sip
> >
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> sip-implementors@cs.columbia.edu for questions on current sip = Use
> sipping@ietf.org for new developments on the application of sip
>
>
> Information contained in this e-mail and any attachments are = intended
> for the use of the addressee only, and may contain confidential
> information of Ubiquity Software Corporation.
> All unauthorized use, disclosure or distribution is strictly
> prohibited.  If you are not the addressee, please notify the = sender
> immediately and destroy all copies of this email.
> Unless otherwise expressly agreed in writing signed by an officer = of
> Ubiquity Software Corporation, nothing in this communication shall = be
> deemed to be legally binding.  Thank you.
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> sip-implementors@cs.columbia.edu for questions on current sip = Use
> sipping@ietf.org for new developments on the application of sip
>

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

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

------=_NextPart_000_0259_01C65331.79F80C80-- --===============1897959139== 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 --===============1897959139==-- From sip-bounces@ietf.org Wed Mar 29 13:24:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfJl-000837-UQ; Wed, 29 Mar 2006 13:22:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfJk-000832-Hx for sip@ietf.org; Wed, 29 Mar 2006 13:22:52 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOfJj-00028B-Tt for sip@ietf.org; Wed, 29 Mar 2006 13:22:52 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2006 10:22:51 -0800 X-IronPort-AV: i="4.03,144,1141632000"; d="scan'208,217"; a="1789837753:sNHT171328368" 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 k2TIMoH9028549; Wed, 29 Mar 2006 10:22:51 -0800 (PST) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 10:22:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] draft-cao-sip-response-identity-00.txt Date: Wed, 29 Mar 2006 10:22:50 -0800 Message-ID: <5F16CF3DBBC7EE45BF6E136F13F5CFEA01E628B3@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-cao-sip-response-identity-00.txt Thread-Index: AcZTUabozUfoimGlSHqENapFJ8Ht/QACJ7ew From: "Feng Cao \(fcao\)" To: "Francois Audet" , "Vijay K. Gurbani" X-OriginalArrivalTime: 29 Mar 2006 18:22:50.0798 (UTC) FILETIME=[C9B7FCE0:01C6535D] X-Spam-Score: 0.5 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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: , Content-Type: multipart/mixed; boundary="===============1536496055==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1536496055== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6535D.C9876115" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6535D.C9876115 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are some needs for providing response identity and we had listed them in the meeting. So far, one of them had received a lot of support from both some offline discussions and the comments in this list, it is to "reveal the proxy's identity as the responder for some response codes, such as provisional, redirect and failure responses."=20 The other two needs listed in the meeting are pasted here again for more feedback. One is to "disclose the response identity for non-dialog session", the other is to "prevent the identity spoofing as early as possible".=20 ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Wednesday, March 29, 2006 8:55 AM To: Vijay K. Gurbani Cc: 'sip@ietf.org'; Drage,Keith (Keith) Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt My take is that there is no agreement that there is a compelling reason to do response identity. That's the main issue. I agree that connected-identity on the other is non-controversial. Vijay K. Gurbani wrote:=20 Drage, Keith (Keith) wrote: =20 (as chair) =20 [...] =20 We do not plan to make any decision about the documentation of draft-cao-sip-response-identity-00.txt until there is some consensus on the mechanisms proposed and support for moving forward. At the moment there have been no posts in favour or against achieving that consensus, and at the moment all we can assume is that there is no support for solving this problem at all. =20 =09 Keith: Is it conceivable to break the milestone into two? One provides solution for knowing who I have connected with (connected-identity), and the other provides the identity of the intermediary or endpoint who issued provisional and non-2xx responses (could use response- identity as a starting point). =09 I don't think there is much debate over connected-identity; the WG agrees that this is the way forward on knowing authoritatively who a UAC is connected to. connected-identity, IIRC, only kicks in when the UAS agrees to session establishment (i.e., a 200 OK is sent out). But what about user agents and intermediaries that issue non-2xx responses? =09 Ostensibly, there could be some advantage in knowing that an intermediary who issued a 3xx is not sending me on a wild goose chase. TLS could be one way to ascertain the identity of the intermediary if I am connected directly (i.e., next hop) to the responder. But what about a chain of TLS proxies where the responding proxy or UAS is a few hops downstream? In that case, response-identity allows the receiver to know who issued a final response. =09 So, does the WG see a need to provide a solution for response identity, which could be defined as the identity of an intermediary issuing a 1xx response or a non-2xx response, or the identity of an endpoint issuing a non-2xx response? If so, then maybe the following can be candidate proposals: =09 1) response-identity. 2) P-A-I applied to responses. 3) H-I header (I don't think this works since in H-I it is the UAC or the proxy that sends a request downstream that adds a H-I header. A UAS echoes the H-I headers, but does not add them pre-emptively, AFAIK). 4) Others...? =09 Thanks, =09 - vijay =20 =09 ________________________________ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C6535D.C9876115 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are some needs for providing = response identity=20 and we had listed them in the meeting. So far, one of them had = received a lot of support from both some offline discussions and=20 the comments in this list, it is to "reveal the = proxy's=20 identity as the responder for some response codes, such as provisional, = redirect=20 and failure responses."

The other two needs listed in = the meeting are=20 pasted here again for more feedback. One is to = "disclose the response identity for non-dialog session", the = other is to=20 "prevent the identity spoofing as early as possible".=20


From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Wednesday, March 29, 2006 8:55 AM
To: Vijay = K.=20 Gurbani
Cc: 'sip@ietf.org'; Drage,Keith = (Keith)
Subject: Re:=20 [Sip] draft-cao-sip-response-identity-00.txt

My take is that there is no agreement that there is a = compelling=20 reason
to do response identity. That's the main issue.

I agree = that=20 connected-identity on the other is non-controversial.

Vijay K. = Gurbani=20 wrote:=20 
Drage, Keith (Keith) wrote:
  
(as chair)
    
[...]
  
We do not plan to make any =
decision about the documentation of
draft-cao-sip-response-identity-00.txt until there is some consensus
on the mechanisms proposed and support for moving forward. At the
moment there have been no posts in favour or against achieving that
consensus, and at the moment all we can assume is that there is no
support for solving this problem at all.
    

Keith: Is it conceivable to break the milestone into two?  One provides
solution for knowing who I have connected with (connected-identity),
and the other provides the identity of the intermediary or endpoint
who issued provisional and non-2xx responses (could use response-
identity as a starting point).

I don't think there is much debate over connected-identity; the WG
agrees that this is the way forward on knowing authoritatively
who a UAC is connected to.  connected-identity, IIRC, only kicks in
when the UAS agrees to session establishment (i.e., a 200 OK is sent
out).  But what about user agents and intermediaries that issue non-2xx
responses?

Ostensibly, there could be some advantage in knowing that an
intermediary who issued a 3xx is not sending me on a wild
goose chase.  TLS could be one way to ascertain the identity of the
intermediary if I am connected directly (i.e., next hop) to the
responder.  But what about a chain of TLS proxies where the responding
proxy or UAS is a few hops downstream?  In that case, response-identity
allows the receiver to know who issued a final response.

So, does the WG see a need to provide a solution for response identity,
which could be defined as the identity of an intermediary issuing a
1xx response or a non-2xx response, or the identity of an endpoint
issuing a non-2xx response?  If so, then maybe the following can be
candidate proposals:

1) response-identity.
2) P-A-I applied to responses.
3) H-I header (I don't think this works since in H-I it is the
   UAC or the proxy that sends a request downstream that adds a
   H-I header.  A UAS echoes the H-I headers, but does not add
   them pre-emptively, AFAIK).
4) Others...?

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.colu=
mbia.edu for questions on current sip
Use sipping@ietf.org for new =
developments on the application of =
sip

------_=_NextPart_001_01C6535D.C9876115-- --===============1536496055== 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 --===============1536496055==-- From sip-bounces@ietf.org Wed Mar 29 13:51:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfjR-0006c4-Ss; Wed, 29 Mar 2006 13:49:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfjQ-0006bt-9A for sip@ietf.org; Wed, 29 Mar 2006 13:49:24 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOfjP-0003WP-RR for sip@ietf.org; Wed, 29 Mar 2006 13:49:24 -0500 Received: (qmail 13588 invoked by uid 0); 29 Mar 2006 18:49:22 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 29 Mar 2006 18:49:22 -0000 Message-ID: <007201c65361$7decec90$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Wed, 29 Mar 2006 20:49:21 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Sip] outbound: summary of issues X-BeenThere: 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="===============2017498964==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2017498964== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01C65372.41438900" This is a multi-part message in MIME format. ------=_NextPart_000_006F_01C65372.41438900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An attempt to summarize issues identified so far, in the form of closed = questions: 1. Configuration of outbound proxies - desire to avoid manual = configuration at the UAC. Do we agree that we want this? 1a If yes, in the outbound draft or as a separate draft? 2. Detection of outbound/keepalive support - desire for dynamic = discovery of support instead of (or perhaps in addition to) static = configuration (the current keepalive=3Dstun flag). Do we agree that we = want this? (several options have been discussed) 3. Deployment scenarios - do we want to support: 3a NAT between the edge proxy and the registrar (or more general: NAT = beyond the first hop) 3b UAC - edge proxy - registrar where the edge proxy adds Path but does = not support outbound/keep-alive 3c UAC - edge proxy - registrar where the edge proxy does not = support/add Path (i.e. it drops out) In addition, there is ongoing (and seemingly endless) discussion on STUN = for TCP, which can be split into 4. Do we mandate only STUN (+ OS keepalive where available), or do we = allow other alternatives? 5. Do we select / document other (primary) mechanisms? { PING, OPTIONS, = other } Regards, jeroen ------=_NextPart_000_006F_01C65372.41438900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
An attempt to summarize issues = identified so far,=20 in the form of closed questions:
 
1. Configuration of outbound proxies - = desire to=20 avoid manual configuration at the UAC. Do we agree that we want=20 this?
1a If yes, in the outbound draft or as = a separate=20 draft?
2. Detection of outbound/keepalive = support=20 - desire for dynamic discovery of support instead of (or = perhaps=20 in addition to) static configuration (the current keepalive=3Dstun = flag). Do we=20 agree that we want this? (several options have been = discussed)
3. Deployment scenarios - do we want to = support:
 3a NAT between the edge proxy and = the=20 registrar (or more general: NAT beyond the first hop)
 3b UAC - edge proxy - = registrar where=20 the edge proxy adds Path but does not support = outbound/keep-alive
 3c UAC - edge proxy - registrar = where the=20 edge proxy does not support/add Path (i.e. it drops = out)
 
In addition, there is ongoing (and = seemingly=20 endless) discussion on STUN for = TCP, which=20 can be split into
4. Do we mandate only STUN (+ OS = keepalive where=20 available), or do we allow other alternatives?
5. Do we select / document other = (primary)=20 mechanisms? { PING, OPTIONS, other }
 
Regards,
 
jeroen
------=_NextPart_000_006F_01C65372.41438900-- --===============2017498964== 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 --===============2017498964==-- From sip-bounces@ietf.org Wed Mar 29 13:56:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfov-0007vJ-Rc; Wed, 29 Mar 2006 13:55:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfou-0007vE-Sk for sip@ietf.org; Wed, 29 Mar 2006 13:55:04 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOfot-0003gs-L3 for sip@ietf.org; Wed, 29 Mar 2006 13:55:04 -0500 Received: from s010600095b9792b5.vc.shawcable.net ([70.79.6.118] helo=[192.168.0.101]) by dns.aliantmedia.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FOfon-0000Sx-Oi; Wed, 29 Mar 2006 12:54:57 -0600 Message-ID: <442AD7FB.4050105@ntt-at.com> Date: Wed, 29 Mar 2006 10:54:51 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt References: <475FF955A05DD411980D00508B6D5FB012749578@en0033exch001u.uk.lucent.com> <442AA643.3050904@lucent.com> <442ABBE1.8050802@nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "sip@ietf.org List" , Francois Audet 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 I like the idea Dean is proposing. They fundamentally solve different issues and I see no need to merge the two and create unnecessary dependency. Regards Shida Dean Willis wrote: > > On Mar 29, 2006, at 10:54 AM, Francois Audet wrote: > >> My take is that there is no agreement that there is a compelling reason >> to do response identity. That's the main issue. >> >> I agree that connected-identity on the other is non-controversial. > > I propose that we amend the charter to show a midsummer deliverable > for connected identity, and use the Elwell draft as a basis for this > deliverable. > > Then we add a later milestone to deliver a decision on whether we will > be adding a new milestone for response identity. > > How does that sound? > > -- > 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 Wed Mar 29 14:12:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOg4M-0006pI-5W; Wed, 29 Mar 2006 14:11:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOg4K-0006pD-Mr for sip@ietf.org; Wed, 29 Mar 2006 14:11:00 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOg4J-0004OG-B9 for sip@ietf.org; Wed, 29 Mar 2006 14:11:00 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWW00I01LB7PQ@siemenscomms.co.uk> for sip@ietf.org; Wed, 29 Mar 2006 20:11:31 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWW00I3NLB75K@siemenscomms.co.uk>; Wed, 29 Mar 2006 20:11:31 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 29 Mar 2006 20:10:58 +0100 Content-return: allowed Date: Wed, 29 Mar 2006 20:10:39 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-cao-sip-response-identity-00.txt To: Dean Willis , Francois Audet Message-id: <50B1CBA96870A34799A506B2313F266708896E7C@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "sip@ietf.org 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 Suits me John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 29 March 2006 19:05 > To: Francois Audet > Cc: sip@ietf.org List > Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt > > > On Mar 29, 2006, at 10:54 AM, Francois Audet wrote: > > > My take is that there is no agreement that there is a compelling > > reason > > to do response identity. That's the main issue. > > > > I agree that connected-identity on the other is non-controversial. > > I propose that we amend the charter to show a midsummer deliverable > for connected identity, and use the Elwell draft as a basis for this > deliverable. > > Then we add a later milestone to deliver a decision on whether we > will be adding a new milestone for response identity. > > How does that sound? > > -- > 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 Wed Mar 29 14:25:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgGw-0004z5-6h; Wed, 29 Mar 2006 14:24:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgGu-0004z0-MM for sip@ietf.org; Wed, 29 Mar 2006 14:24:00 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOgGt-0004mj-Dv for sip@ietf.org; Wed, 29 Mar 2006 14:24:00 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWW00M01LWW1L@siemenscomms.co.uk> for sip@ietf.org; Wed, 29 Mar 2006 20:24:32 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWW00IAYLWV5K@siemenscomms.co.uk>; Wed, 29 Mar 2006 20:24:31 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 29 Mar 2006 20:23:58 +0100 Content-return: allowed Date: Wed, 29 Mar 2006 20:23:22 +0100 From: "Elwell, John" Subject: RE: [Sip] outbound: summary of issues To: Jeroen van Bemmel , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708896E7E@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 29 March 2006 19:49 > To: sip@ietf.org > Subject: [Sip] outbound: summary of issues > > An attempt to summarize issues identified so far, in the form > of closed questions: > > 1. Configuration of outbound proxies - desire to avoid manual > configuration at the UAC. Do we agree that we want this? > 1a If yes, in the outbound draft or as a separate draft? > 2. Detection of outbound/keepalive support - desire for > dynamic discovery of support instead of (or perhaps in > addition to) static configuration (the current keepalive=stun > flag). Do we agree that we want this? (several options have > been discussed) [JRE] I can't recall what was wrong with just an option tag in the Supported header of the REGISTER response. 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 Wed Mar 29 14:38:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgSo-00033Q-MQ; Wed, 29 Mar 2006 14:36:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgSn-00032V-3p for sip@ietf.org; Wed, 29 Mar 2006 14:36:17 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOgSl-0005Ct-Nl for sip@ietf.org; Wed, 29 Mar 2006 14:36:17 -0500 Received: (qmail 24123 invoked by uid 0); 29 Mar 2006 19:36:14 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 29 Mar 2006 19:36:14 -0000 Message-ID: <013a01c65368$0a06cd80$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Elwell, John" , References: <50B1CBA96870A34799A506B2313F266708896E7E@ntht201e.siemenscomms.co.uk> Subject: Re: [Sip] outbound: summary of issues Date: Wed, 29 Mar 2006 21:36:13 +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.2670 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 John, see inline ----- Original Message ----- From: "Elwell, John" To: "Jeroen van Bemmel" ; Sent: Wednesday, March 29, 2006 9:23 PM Subject: RE: [Sip] outbound: summary of issues > > >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: 29 March 2006 19:49 >> To: sip@ietf.org >> Subject: [Sip] outbound: summary of issues >> >> An attempt to summarize issues identified so far, in the form >> of closed questions: >> >> 1. Configuration of outbound proxies - desire to avoid manual >> configuration at the UAC. Do we agree that we want this? >> 1a If yes, in the outbound draft or as a separate draft? >> 2. Detection of outbound/keepalive support - desire for >> dynamic discovery of support instead of (or perhaps in >> addition to) static configuration (the current keepalive=stun >> flag). Do we agree that we want this? (several options have >> been discussed) > [JRE] I can't recall what was wrong with just an option tag in the > Supported > header of the REGISTER response. That would indicate that the registrar supports outbound, but says nothing about the edge proxy. The risk is that the UAC starts poking it with STUN requests while it is not supported. An outbound proxy URI with keepalive=stun would indicate proxy support, but that would only be an informed guess - there is the possibility for misconfiguration. To avoid this, it would be good if the proxy would actively indicate that it supports outbound (in particular STUN). Jeroen > > 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 Wed Mar 29 14:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgTW-0003Or-U8; Wed, 29 Mar 2006 14:37:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgTV-0003ML-Be for sip@ietf.org; Wed, 29 Mar 2006 14:37:01 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOgTU-0005G2-4G for sip@ietf.org; Wed, 29 Mar 2006 14:37:01 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 562A78F5; Wed, 29 Mar 2006 21:36:59 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 21:36:58 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 21:36:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] draft-ietf-sip-outbound Date: Wed, 29 Mar 2006 21:36:58 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C03@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZTKI+OThZFvNboQTOT9ZQUwuZU5AAAJYGQAAi6dYQABrKMgA== From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Elwell, John" , "Chris Boulton" , "Hisham Khartabil" , "Samir Srivastava" X-OriginalArrivalTime: 29 Mar 2006 19:36:58.0323 (UTC) FILETIME=[24A67230:01C65368] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: d6c15d82a53e26283536b4a751453103 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="===============1929820875==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1929820875== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65368.24AB2BB3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65368.24AB2BB3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 As I said, it doesn't have to be in the document - it can be in the = meeting report. =20 All I'm asking for, since I wasn't able to attend the meeting, are the = arguments that were presented, which were then used for people to vote = for a specific solution. Is that too much to ask for???=20 =20 I don't think what I'm asking for is going to delay the work on the = draft. A choise has been made, and we should stick to it.=20 =20 Regards, =20 Christer ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: 29. maaliskuuta 2006 19:23 To: Christer Holmberg (JO/LMF); Elwell, John; Chris Boulton; Hisham = Khartabil; Samir Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound I don't understand why we need to do this. We've never done this before = in IETF that I can remember, and it seems to me to bean undue burden on the editors. Being a bunch = of engineers, we risk arguing endlessly about the justification itself (like we did on the mailing = list for 12 months). Instead of "making it go away", this explanation will just bring us back = 12 months. If the vote had been really close, maybe, but it wasn't: it was me and = four others against 185. I'd rather we spend time issuing the draft, and finishing up the vast = number of drafts waiting in the queue. ---- Fran=E7ois AUDET, Nortel Networks mailto:audet@nortel.com -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: Wed 29-Mar-06 4:10 AM To: Elwell, John; Chris Boulton; Hisham Khartabil; Srivastava, Samir = [SC100:8826:EXCH] Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Hi, If the meeting report will show why this solution was chosen, compared to others, and the arguments/pros/cons that were presented for the different solutions, before people were asked to raise their hand for one of the solutions, I will be happy. If the meeting report will only say "There was a concensus for STUN" it won't help very much, and I am pretty sure questions will come up again in the future ("I have just read this RFC, and I wonder why I can't use instead."). Also, since the network initiated keep-alives obviously were not discussed (please correct me if I'm wrong), I wonder if it would be possible to add some text in the draft indicating it is "out of the scope of the document", it is "for future work", or whatever, because as far as I am aware the whole discussion/scope has been about UA initiaded keep-alives. Regards, Christer -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: 29. maaliskuuta 2006 15:01 To: Chris Boulton; Hisham Khartabil; Samir Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Yes, the mailing list archives and meeting minutes will show the reasons. I don't see the need for yet another draft and endless discussion during its production. Don't we have enough work to do? Let's just move on and get outbound finished. John > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 29 March 2006 12:47 > To: Hisham Khartabil; Samir Srivastava > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-outbound > > I'm with Hisham on this - this has been discussed at length and a > choice has been made. I certainly don't see the need to add another > draft - we have way too many to read as it is. I was also at the > meeting and feel that such decisions should just be accepted (the > consensus was > overwhelming) - otherwise we will find ourselves stuck on the same old > IETF roundabout. > > Chris. > > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: 29 March 2006 08:42 > To: Samir Srivastava > Cc: sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-outbound > > I don't agree. This is being done without documenting it. Once > documented, it will never go away. We all know that. > > Hisham > > On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote: > > > > > This seems like a good reason for this (or another) draft > to discuss > > the > > alternative solutions for use until the STUN solution is > supported by > > both devices. Since the draft is basically silent, vendors > will just > > fallback to flooding the network with their favorite SIP request > > (REGISTERs, etcetera) for solving the problem without much > guidance or > > potential optimizations. > > > > > > SS>> I agree. > > > > I captured following from SIPIT-16 (Apr 05) report. I couldn't find > > SIPIT-17 report from archive. Can somebody update on outbound from > > that. > > > > "There were 10 teams with implementations doing various things to > > keep NAT bindings alive (sending CRLFs, empty media packets, etc). > > The remainder were not attempting to address the problem at this > > time." > > > > There are *Empty Media Packets* too !! > > > > > > Thx > > Samir > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > Information contained in this e-mail and any attachments are intended > for the use of the addressee only, and may contain confidential > information of Ubiquity Software Corporation. > All unauthorized use, disclosure or distribution is strictly > prohibited. If you are not the addressee, please notify the sender > immediately and destroy all copies of this email. > Unless otherwise expressly agreed in writing signed by an officer of > Ubiquity Software Corporation, nothing in this communication shall be > deemed to be legally binding. Thank you. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C65368.24AB2BB3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-ietf-sip-outbound
Hi,
 
As I=20 said, it doesn't have to be in the document - it can be in the meeting=20 report.
 
All=20 I'm asking for, since I wasn't able to attend the meeting, are the=20 arguments that were presented, which were then used for people to vote = for a=20 specific solution. Is that too much to ask for???
 
I=20 don't think what I'm asking for is going to delay the work on the draft. = A=20 choise has been made, and we should stick to it.
 
Regards,
 
Christer

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: 29. maaliskuuta 2006 19:23
To: Christer = Holmberg=20 (JO/LMF); Elwell, John; Chris Boulton; Hisham Khartabil; Samir=20 Srivastava
Cc: sip@ietf.org
Subject: RE: [Sip]=20 draft-ietf-sip-outbound

I don't understand why we need to do this. We've never = done this=20 before in IETF that I can remember,
and it seems to me to bean undue = burden=20 on the editors.  Being a bunch of engineers, we risk = arguing
endlessly=20 about the justification itself (like we did on the mailing list for 12=20 months).

Instead of "making it go away", this explanation will = just bring=20 us back 12 months.

If the vote had been really close, maybe, but = it=20 wasn't: it was me and four others against 185.

I'd rather we = spend time=20 issuing the draft, and finishing up the vast number of drafts waiting in = the
queue.

----
Fran=E7ois AUDET, Nortel Networks
mailto:audet@nortel.com


<= BR>-----Original=20 Message-----
From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@e= ricsson.com]
Sent:=20 Wed 29-Mar-06 4:10 AM
To: Elwell, John; Chris Boulton; Hisham = Khartabil;=20 Srivastava, Samir [SC100:8826:EXCH]
Cc: sip@ietf.org
Subject: RE: = [Sip]=20 draft-ietf-sip-outbound


Hi,

If the meeting report will = show=20 why this solution was chosen, compared
to others, and the = arguments/pros/cons=20 that were presented for the
different solutions, before people were = asked to=20 raise their hand for
one of the solutions, I will be happy.

If = the=20 meeting report will only say "There was a concensus for STUN" = it
won't help=20 very much, and I am pretty sure questions will come up again
in the = future=20 ("I have just read this RFC, and I wonder why I can't=20 use
<insert-your-favorite-method> instead.").

Also, = since the=20 network initiated keep-alives obviously were not
discussed (please = correct me=20 if I'm wrong), I wonder if it would be
possible to add some text in = the draft=20 indicating it is "out of the
scope of the document", it is "for = future work",=20 or whatever, because as
far as I am aware the whole discussion/scope = has been=20 about UA=20 initiaded
keep-alives.

Regards,

Christer



= -----Original=20 Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent:=20 29. maaliskuuta 2006 15:01
To: Chris Boulton; Hisham Khartabil; Samir = Srivastava
Cc: sip@ietf.org
Subject: RE: [Sip]=20 draft-ietf-sip-outbound

Yes, the mailing list archives and = meeting=20 minutes will show the
reasons. I don't see the need for yet another = draft and=20 endless
discussion during its production. Don't we have enough work = to do?=20 Let's
just move on and get outbound finished.

John

> = -----Original Message-----
> From: Chris Boulton [mailto:cboulton@ubiquity.net]>=20 Sent: 29 March 2006 12:47
> To: Hisham Khartabil; Samir = Srivastava
>=20 Cc: sip@ietf.org
> Subject: RE: [Sip]=20 draft-ietf-sip-outbound
>
> I'm with Hisham on this - this = has been=20 discussed at length and a
> choice has been made.  I = certainly don't=20 see the need to add another
> draft - we have way too many to read = as it=20 is.  I was also at the
> meeting and feel that such decisions = should=20 just be accepted (the
> consensus was
> overwhelming) - = otherwise we=20 will find ourselves stuck on the same old

> IETF=20 roundabout.
>
> Chris.
>
>
> -----Original = Message-----
> From: Hisham Khartabil [mailto:hisham.khartabil@telio.n= o]
>=20 Sent: 29 March 2006 08:42
> To: Samir Srivastava
> Cc:=20 sip@ietf.org
> Subject: Re: [Sip] = draft-ietf-sip-outbound
>
>=20 I don't agree. This is being done without documenting it. Once
>=20 documented, it will never go away. We all know that.
>
>=20 Hisham
>
> On Mar 28, 2006, at 10:38 PM, Samir Srivastava=20 wrote:
>
> >
> > This seems like a good reason = for this=20 (or another) draft
> to discuss
> > the
> > = alternative=20 solutions for use until the STUN solution is
> supported = by
> >=20 both devices.  Since the draft is basically silent, vendors
> = will=20 just
> > fallback to flooding the network with their favorite = SIP=20 request
> > (REGISTERs, etcetera) for solving the problem = without=20 much
> guidance or
> > potential optimizations.
>=20 >
> >
> > SS>> I agree.
> >
> = > I=20 captured following from SIPIT-16 (Apr 05) report. I couldn't = find
> >=20 SIPIT-17 report from archive.  Can somebody update on outbound = from
>=20 > that.
> >
> > "There were 10 teams with = implementations=20 doing various things to
> > keep NAT bindings alive (sending = CRLFs,=20 empty media packets, etc).
> > The remainder were not = attempting to=20 address the problem at this
> > time."
> >
> = > There=20 are *Empty Media Packets* too !!
> >
> >
> >=20 Thx
> > Samir
> >
> >
> >=20 _______________________________________________
> > Sip mailing = list  https://www1.ietf.org= /mailman/listinfo/sip
>=20 > 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
>=20 > 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 =20 https://www1.ietf.org= /mailman/listinfo/sip
>=20 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=20 sip
>
>
> Information contained in this e-mail and any = attachments are intended
> for the use of the addressee only, and = may=20 contain confidential
> information of Ubiquity Software=20 Corporation.
> All unauthorized use, disclosure or distribution is = strictly
> prohibited.  If you are not the addressee, please = notify=20 the sender
> immediately and destroy all copies of this = email.
>=20 Unless otherwise expressly agreed in writing signed by an officer = of
>=20 Ubiquity Software Corporation, nothing in this communication shall = be
>=20 deemed to be legally binding.  Thank you.
>
>
>=20 _______________________________________________
> Sip mailing = list =20 https://www1.ietf.org= /mailman/listinfo/sip
>=20 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=20 sip
>

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

_______________________________________________
Sip = mailing=20 list  https://www1.ietf.org= /mailman/listinfo/sip
This=20 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=20 sip


------_=_NextPart_001_01C65368.24AB2BB3-- --===============1929820875== 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 --===============1929820875==-- From sip-bounces@ietf.org Wed Mar 29 14:46:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgaO-0004qB-Qc; Wed, 29 Mar 2006 14:44:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgaN-0004pW-Ma for sip@ietf.org; Wed, 29 Mar 2006 14:44:07 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOgaN-0005Xr-8J for sip@ietf.org; Wed, 29 Mar 2006 14:44:07 -0500 Received: (qmail 9001 invoked by uid 0); 29 Mar 2006 19:44:05 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 29 Mar 2006 19:44:05 -0000 Message-ID: <013b01c65369$22b55b20$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Hadriel Kaplan" References: <01bd01c65309$87c036d0$6501a8c0@acmepacket.com> Subject: Re: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Wed, 29 Mar 2006 21:44:04 +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.2670 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sip@ietf.org, '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 Hadriel, see inline Jeroen ----- Original Message ----- From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" Cc: ; "'Dean Willis'" Sent: Wednesday, March 29, 2006 10:19 AM Subject: RE: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" > Hi Jeroen, > Comments inline... > >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: Tuesday, March 28, 2006 1:14 AM >> >> > But there are 3261 compliant proxies out there that don't support Path. >> > So >> > you will not know if the register went through one of those and hit an >> > outbound registrar, vs. there was no proxy. I think a proxy-require is >> > the >> > only safe bet (and it would work across multiple proxies). It only >> means >> > an >> > extra round-trip if it fails, and the truth is you do require the proxy >> to >> > support something, so why not use the header defined for that? >> >> If the outbound proxy does not support Path, it also does not support >> outbound. In either case the UAC could detect this (i.e. no Path header >> matching outbound proxy -> proxy does not support outbound). The problem >> could be with proxies that ~do~ support Path, but for one reason or >> another >> do not wish to be in the path for inbound requests. On the other hand: >> keepalive is only required for the path that inbound requests follow! > > Actually, I'm pretty sure keepalive is required for the first sip box the > UA > hits (the one outbound and inbound requests follow), because your > nat-hole-flow is to it. I don't see how it's possible for your Register > to > go to a first proxy which is not in both the inbound and outbound request > flow. How would the request get back through the nat-hole or TCP socket? > That was exactly my point: what happens if the first proxy does not add Path? Assuming there is NAT (or something else preventing direct reachability), the UAC would have to establish a flow with the next hop on the path, i.e. the host corresponding to the last entry in the Path header value (possible issue as you mention below). If there is no Path header, it will have to connect directly to the registrar. > More importantly, the local proxy could very well do Path but NOT support > outbound. So you'll be doing it when you shouldn't. > The idea was to add a flag to the Path header. When the flag isn't there, it means outbound is not supported by the proxy that inserted that Path header (hence no STUN poking) > Second, it may be just a registrar without a proxy (no path header). So > you > won't be doing outbound when you should. (at least, I don't think a > registrar supporting Path actually inserts it if it's an empty set, and it > itself is not in the uri set) > I agree that the registrar wouldn't insert a Path header. So the rule should be: if there are Path headers, check if the last value contains a flag. If no Path headers, check for Supported : outbound (and start keepalives if found). > Fourth, if it's a proxy that does Path, there is no assurance the URI you > get in the returned 200ok Path is its URI to you. Proxies can have > multiple > interfaces, and the Path URI will be the one pointing to the registrar, > no? > So you won't be doing outbound when you should. > I think this is a matter of properly defining semantics. A flag in the Path header (or in the URI) would have to mean that the element supports STUN on all interfaces. It could be that the UAC cannot match the URI in the Path header to a host that it recognises / can reach, but I don't think it needs to. Just looking for the flag in the last Path header would suffice Jeroen > -hadriel > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 15:02:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgq5-0005gJ-0C; Wed, 29 Mar 2006 15:00:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgq3-0005gE-Pp for sip@ietf.org; Wed, 29 Mar 2006 15:00:19 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOgq3-000655-Cc for sip@ietf.org; Wed, 29 Mar 2006 15:00:19 -0500 Received: (qmail 31712 invoked by uid 0); 29 Mar 2006 20:00:18 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 29 Mar 2006 20:00:18 -0000 Message-ID: <016c01c6536b$6687f4f0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Hadriel Kaplan" , "'Brett Tate'" , References: <01cc01c65315$26022050$6501a8c0@acmepacket.com> Subject: Re: [Sip] How to indicate during proxydiscoverythataproxysupports"outbound" Date: Wed, 29 Mar 2006 22:00:15 +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.2670 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 see inline > Hi Brett, > >> -----Original Message----- >> From: Brett Tate [mailto:brett@broadsoft.com] >> Sent: Tuesday, March 28, 2006 1:45 PM >> >> And concerning the potential use of option tags within Require, >> Supported, >> etcetera, I do not think they are adequate since they do not indicate >> which >> device added it. >> >> Via header manipulation would likely work; however it introduces a little >> extra processing overhead on the target. UAC adds Via parameter >> "outbound". >> And when the proxy/UAS observes it and supports receiving stun on this >> port/connection, it adds a parameter like "outbound=supported" or >> "outbound=required". > > Oh, an excellent idea. It's slightly less secure than a proxy-require, > but > it's a test without a failure round-trip. And it's hardly much overhead > compared to being the edge proxy or UA for outbound anyway. And it's > potentially a re-usable concept for a future draft for a proxy-to-proxy > keepalive check. > This was the gist of the idea I posted too. However, consider the following scenario: UAC - P1 - P2 - registrar UAC, P1, and the registrar all support outbound, P2 does not and also does not add a Path header. In this case, P1 should initiate a flow directly to the registrar, and keep it alive. However, keepalive support cannot be detected from the top Via header in the response, since that was added by P2! In this particular case P1 could check for Supported : outbound and it could work (assuming you go along with proxies initiating new flows, which probably has security implications). However, then consider an additional proxy P3 in the scenario, and it would break once more. Another issue with proxy-proxy keepalive is: how would the UAC be notified of flow failure? Jeroen > The only down-side is etiquette requires you to send the text for the > draft > if other people agree. ;) > > -hadriel > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 15:03:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgr4-0006LQ-0H; Wed, 29 Mar 2006 15:01:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgr2-0006LL-Rt for sip@ietf.org; Wed, 29 Mar 2006 15:01:20 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOgr2-000682-8T for sip@ietf.org; Wed, 29 Mar 2006 15:01:20 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9FE5817F; Wed, 29 Mar 2006 22:01:19 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 22:01:19 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 22:01: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 Subject: RE: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Date: Wed, 29 Mar 2006 22:01:18 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C05@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Thread-Index: AcZTaTKxzDSRPw0/SCmuBBJ3u16jyQAAZiHQ From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Hadriel Kaplan" X-OriginalArrivalTime: 29 Mar 2006 20:01:19.0411 (UTC) FILETIME=[8B86C830:01C6536B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: sip@ietf.org, 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, If we talk about a flag in the Path header (or Via header) I think we need to look at it from a little wider, conceptual, perspective.=20 What you are talking about is a way for proxies to indicate capabilities and support of extensions. So, if my proxy is allowed to indicate outbound, why can't it then also indicate support for session-timer, PRACK, pre-conditdions, ? Shall we only do a "hack" for outbound, or shall we look at it from a more general perspective? Regards, Christer =20 -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 29. maaliskuuta 2006 22:44 To: Hadriel Kaplan Cc: sip@ietf.org; 'Dean Willis' Subject: Re: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Hadriel, see inline Jeroen ----- Original Message ----- From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" Cc: ; "'Dean Willis'" Sent: Wednesday, March 29, 2006 10:19 AM Subject: RE: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" > Hi Jeroen, > Comments inline... > >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: Tuesday, March 28, 2006 1:14 AM >> >> > But there are 3261 compliant proxies out there that don't support Path. >> > So >> > you will not know if the register went through one of those and hit >> > an outbound registrar, vs. there was no proxy. I think a=20 >> > proxy-require is the only safe bet (and it would work across=20 >> > multiple proxies). It only >> means >> > an >> > extra round-trip if it fails, and the truth is you do require the=20 >> > proxy >> to >> > support something, so why not use the header defined for that? >> >> If the outbound proxy does not support Path, it also does not support >> outbound. In either case the UAC could detect this (i.e. no Path=20 >> header matching outbound proxy -> proxy does not support outbound).=20 >> The problem could be with proxies that ~do~ support Path, but for one >> reason or another do not wish to be in the path for inbound requests. >> On the other hand: >> keepalive is only required for the path that inbound requests follow! > > Actually, I'm pretty sure keepalive is required for the first sip box=20 > the UA hits (the one outbound and inbound requests follow), because=20 > your nat-hole-flow is to it. I don't see how it's possible for your=20 > Register to go to a first proxy which is not in both the inbound and=20 > outbound request flow. How would the request get back through the=20 > nat-hole or TCP socket? > That was exactly my point: what happens if the first proxy does not add Path? Assuming there is NAT (or something else preventing direct reachability), the UAC would have to establish a flow with the next hop on the path, i.e. the host corresponding to the last entry in the Path header value (possible issue as you mention below). If there is no Path header, it will have to connect directly to the registrar. > More importantly, the local proxy could very well do Path but NOT=20 > support outbound. So you'll be doing it when you shouldn't. > The idea was to add a flag to the Path header. When the flag isn't there, it means outbound is not supported by the proxy that inserted that Path header (hence no STUN poking) > Second, it may be just a registrar without a proxy (no path header). =20 > So you won't be doing outbound when you should. (at least, I don't=20 > think a registrar supporting Path actually inserts it if it's an empty > set, and it itself is not in the uri set) > I agree that the registrar wouldn't insert a Path header. So the rule should be: if there are Path headers, check if the last value contains a flag. If no Path headers, check for Supported : outbound (and start keepalives if found). > Fourth, if it's a proxy that does Path, there is no assurance the URI=20 > you get in the returned 200ok Path is its URI to you. Proxies can=20 > have multiple interfaces, and the Path URI will be the one pointing to > the registrar, no? > So you won't be doing outbound when you should. > I think this is a matter of properly defining semantics. A flag in the Path=20 header (or in the URI) would have to mean that the element supports STUN on=20 all interfaces. It could be that the UAC cannot match the URI in the Path=20 header to a host that it recognises / can reach, but I don't think it needs=20 to. Just looking for the flag in the last Path header would suffice Jeroen > -hadriel > >=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 Mar 29 15:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgvK-0000Hf-OR; Wed, 29 Mar 2006 15:05:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgvJ-0000HX-PB for sip@ietf.org; Wed, 29 Mar 2006 15:05:45 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOgvJ-0006KH-Fk for sip@ietf.org; Wed, 29 Mar 2006 15:05:45 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWW00801NUHYT@siemenscomms.co.uk> for sip@ietf.org; Wed, 29 Mar 2006 21:06:17 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWW004B6NUHUH@siemenscomms.co.uk>; Wed, 29 Mar 2006 21:06:17 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 29 Mar 2006 21:05:44 +0100 Content-return: allowed Date: Wed, 29 Mar 2006 21:05:29 +0100 From: "Elwell, John" Subject: RE: [Sip] outbound: summary of issues To: Jeroen van Bemmel , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708896E99@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT 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 Jeroen, Thanks for your explanation. However, could we not limit use of Supported outbound to the edge proxy. Since an edge proxy would not connect to the registrar using outbound (I assume connect-reuse would be used instead), then there is no reason for the registrar to place Supported outbound in the REGISTER response. This could be left for the edge proxy to insert. If it is felt inappropriate for a proxy to insert a Supported header tag, then perhaps there is something else it can insert. This would seem much more reliable than depending on configuration. John > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 29 March 2006 20:36 > To: Elwell, John; sip@ietf.org > Subject: Re: [Sip] outbound: summary of issues > > John, > > see inline > > > ----- Original Message ----- > From: "Elwell, John" > To: "Jeroen van Bemmel" ; > Sent: Wednesday, March 29, 2006 9:23 PM > Subject: RE: [Sip] outbound: summary of issues > > > > > > > >> -----Original Message----- > >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >> Sent: 29 March 2006 19:49 > >> To: sip@ietf.org > >> Subject: [Sip] outbound: summary of issues > >> > >> An attempt to summarize issues identified so far, in the form > >> of closed questions: > >> > >> 1. Configuration of outbound proxies - desire to avoid manual > >> configuration at the UAC. Do we agree that we want this? > >> 1a If yes, in the outbound draft or as a separate draft? > >> 2. Detection of outbound/keepalive support - desire for > >> dynamic discovery of support instead of (or perhaps in > >> addition to) static configuration (the current keepalive=stun > >> flag). Do we agree that we want this? (several options have > >> been discussed) > > [JRE] I can't recall what was wrong with just an option tag in the > > Supported > > header of the REGISTER response. > > That would indicate that the registrar supports outbound, but > says nothing > about the edge proxy. The risk is that the UAC starts poking > it with STUN > requests while it is not supported. > > An outbound proxy URI with keepalive=stun would indicate > proxy support, but > that would only be an informed guess - there is the possibility for > misconfiguration. To avoid this, it would be good if the proxy would > actively indicate that it supports outbound (in particular STUN). > > Jeroen > > > > > 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 Wed Mar 29 15:29:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOhGV-0002j0-0H; Wed, 29 Mar 2006 15:27:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOhGT-0002iv-JN for sip@ietf.org; Wed, 29 Mar 2006 15:27:37 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOhGS-0007Rl-5d for sip@ietf.org; Wed, 29 Mar 2006 15:27:37 -0500 Received: from s010600095b9792b5.vc.shawcable.net ([70.79.6.118] helo=[192.168.0.101]) by dns.aliantmedia.net with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.52) id 1FOhGL-0008CD-19; Wed, 29 Mar 2006 14:27:29 -0600 Message-ID: <442AEDAB.7010104@ntt-at.com> Date: Wed, 29 Mar 2006 12:27:23 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Feng Cao (fcao)" Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt References: <5F16CF3DBBC7EE45BF6E136F13F5CFEA01E628B3@xmb-sjc-224.amer.cisco.com> In-Reply-To: <5F16CF3DBBC7EE45BF6E136F13F5CFEA01E628B3@xmb-sjc-224.amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: sip@ietf.org, Francois Audet , "Drage, Keith \(Keith\)" , "Vijay K. Gurbani" 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 Feng; I don't really know how much of the problem can really be solved here, and I would like to know because it seems like I am just not getting it. Proxy non-adjacent to UA sending a response identity alone does not seem to provide enough information that the responding proxy really is a valid proxy, meaning that it's not a MitM. Unless you can show that the request indeed ended up at the proxy responding with the identity, response-identity alone seems insufficient, may be useful but insufficient. I personally think H-I, if signaling path is secured(sips or TLS proxy chain) may be sufficient. Regarding your second issue, what kind of non-dialog session might find the response-identity useful? I just can't seem to imagine a use-case that's sensible and I am very interested in hearing its usage. Lastly, I thought about the last issue you brought up about identity spoofing and I do see some value in it, as you can probably track the malicious user who made a plank call more easily if identity header is available. I guess if identity header is available you are able to inquire or sue the responsible domain. But connected-identity provides the same benefit by providing identity header in the request in opposite direction simply at a different stage of the call. If it's all about providing this at the call setup time because you don't want to exchange any media with the malicious responder, then you can define a pre-condition where both users need to provide an identity, in which case, media exchange won't start until connected-identity is provided through an UPDATE or re-INVITE, upon which UAC or calling proxy can apply its local policy using the response-identity provided and decide whether to proceed with the media exchange etc. Regards Shida Feng Cao (fcao) wrote: > > There are some needs for providing response identity and we had listed > them in the meeting. So far, one of them had received a lot of support > from both some offline discussions and the comments in this list, it > is to "reveal the proxy's identity as the responder for some response > codes, such as provisional, redirect and failure responses." > > The other two needs listed in the meeting are pasted here again for > more feedback. One is to "disclose the response identity for > non-dialog session", the other is to "prevent the identity spoofing as > early as possible". > > > ------------------------------------------------------------------------ > *From:* Francois Audet [mailto:audet@nortel.com] > *Sent:* Wednesday, March 29, 2006 8:55 AM > *To:* Vijay K. Gurbani > *Cc:* 'sip@ietf.org'; Drage,Keith (Keith) > *Subject:* Re: [Sip] draft-cao-sip-response-identity-00.txt > > My take is that there is no agreement that there is a compelling reason > to do response identity. That's the main issue. > > I agree that connected-identity on the other is non-controversial. > > Vijay K. Gurbani wrote: >> Drage, Keith (Keith) wrote: >> >>> (as chair) >>> >> [...] >> >>> We do not plan to make any decision about the documentation of >>> draft-cao-sip-response-identity-00.txt until there is some consensus >>> on the mechanisms proposed and support for moving forward. At the >>> moment there have been no posts in favour or against achieving that >>> consensus, and at the moment all we can assume is that there is no >>> support for solving this problem at all. >>> >> >> Keith: Is it conceivable to break the milestone into two? One provides >> solution for knowing who I have connected with (connected-identity), >> and the other provides the identity of the intermediary or endpoint >> who issued provisional and non-2xx responses (could use response- >> identity as a starting point). >> >> I don't think there is much debate over connected-identity; the WG >> agrees that this is the way forward on knowing authoritatively >> who a UAC is connected to. connected-identity, IIRC, only kicks in >> when the UAS agrees to session establishment (i.e., a 200 OK is sent >> out). But what about user agents and intermediaries that issue non-2xx >> responses? >> >> Ostensibly, there could be some advantage in knowing that an >> intermediary who issued a 3xx is not sending me on a wild >> goose chase. TLS could be one way to ascertain the identity of the >> intermediary if I am connected directly (i.e., next hop) to the >> responder. But what about a chain of TLS proxies where the responding >> proxy or UAS is a few hops downstream? In that case, response-identity >> allows the receiver to know who issued a final response. >> >> So, does the WG see a need to provide a solution for response identity, >> which could be defined as the identity of an intermediary issuing a >> 1xx response or a non-2xx response, or the identity of an endpoint >> issuing a non-2xx response? If so, then maybe the following can be >> candidate proposals: >> >> 1) response-identity. >> 2) P-A-I applied to responses. >> 3) H-I header (I don't think this works since in H-I it is the >> UAC or the proxy that sends a request downstream that adds a >> H-I header. A UAS echoes the H-I headers, but does not add >> them pre-emptively, AFAIK). >> 4) Others...? >> >> 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 > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 15:50:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOhaq-00048S-W7; Wed, 29 Mar 2006 15:48:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOhap-00048N-91 for sip@ietf.org; Wed, 29 Mar 2006 15:48:39 -0500 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 1FOhao-000855-WE for sip@ietf.org; Wed, 29 Mar 2006 15:48:39 -0500 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A2A10270; Wed, 29 Mar 2006 15:48:33 -0500 Message-ID: <002f01c65372$27a575d0$800101df@acmepacket.com> From: "Bob Penfield" To: "Jeroen van Bemmel" , References: <007201c65361$7decec90$31713b51@BEMBUSTER> Subject: Re: [Sip] outbound: summary of issues Date: Wed, 29 Mar 2006 15:48:38 -0500 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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 inline ----- Original Message ----- From: "Jeroen van Bemmel" > >An attempt to summarize issues identified so far, in the >form of closed questions: > >1. Configuration of outbound proxies - desire to avoid > manual configuration at the UAC. Do we agree that we > want this? Yes, however, if we do #2 below so that a UA can definitively determine that the edge proxy supports outbound and the keepalive, and that the home proxy supports outbound (i.e. sip.instance and reg-id), this would not necessarily be needed immediately. > 1a If yes, in the outbound draft or as a separate draft? Again, if we do #2 below, it should be in a separate draft so that it does not delay the current outbound draft. > 2. Detection of outbound/keepalive support - desire for > dynamic discovery of support instead of (or perhaps > in addition to) static configuration (the current > keepalive=stun flag). Do we agree that we want this? > (several options have been discussed) The UA needs to determine definitively that the edge proxy that the UA connects to support outbound and the STUN keepalive. It also needs to determine whether or not the home-proxy/registrar supports outbound before it sends REGISTERs using the reg-id. > 3. Deployment scenarios - do we want to support: > 3a NAT between the edge proxy and the registrar (or more > general: NAT beyond the first hop) > 3b UAC - edge proxy - registrar where the edge proxy adds > Path but does not support outbound/keep-alive > 3c UAC - edge proxy - registrar where the edge proxy does > not support/add Path (i.e. it drops out) I would say no, not with this draft. Those seem like different problems to me. The most pressing requirement is defining a mechanism for a UA to have an outbound TCP/TLS connection by which it can receive inbound requests. To me, this requires that there be a persistant connection to the first proxy (whether it be the edge proxy or the registrar). You could probably use connection-reuse and the keepalive for 3a. With 3b, if the edge does not support outbound, it would not send inbound requests over the existing connection, so I don't see how that would work at all. With 3c, the UAC would have to establish an outbound connection directly with the registrar in order to receive inbound requests. >In addition, there is ongoing (and seemingly endless) >discussion on STUN >for TCP, which can be split into >4. Do we mandate only STUN (+ OS keepalive where available), > or do we allow other alternatives? That was the consensus decision at IETF 65 >5. Do we select / document other (primary) mechanisms? > { PING, OPTIONS, other } Based on 4 above, No. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 29 16:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOhyf-0005Hn-CQ; Wed, 29 Mar 2006 16:13:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOhye-0005HG-FU for sip@ietf.org; Wed, 29 Mar 2006 16:13:16 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOhye-0000zi-20 for sip@ietf.org; Wed, 29 Mar 2006 16:13:16 -0500 Received: (qmail 18900 invoked by uid 0); 29 Mar 2006 21:13:14 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 29 Mar 2006 21:13:14 -0000 Message-ID: <017f01c65375$97234d30$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Elwell, John" , References: <50B1CBA96870A34799A506B2313F266708896E99@ntht201e.siemenscomms.co.uk> Subject: Re: [Sip] outbound: summary of issues Date: Wed, 29 Mar 2006 23:13:13 +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.2670 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 John, Yes, this is what one thread of the discussion was about, and you seem to agree with #2 below Proxies inserting Supported: I think that would indeed be inappropriate as you indicate. What about feature tags a la callerprefs (RFC3841) in Path and Record-Route headers? Path: ;extensions="outbound" This would imply that proxies cannot indicate extensions without Record-Routing, but since the information is only relevant when the proxy stays in the path for next requests, this somehow feels appropriate to me Regards, jeroen ----- Original Message ----- From: "Elwell, John" To: "Jeroen van Bemmel" ; Sent: Wednesday, March 29, 2006 10:05 PM Subject: RE: [Sip] outbound: summary of issues > Jeroen, > > Thanks for your explanation. However, could we not limit use of Supported > outbound to the edge proxy. Since an edge proxy would not connect to the > registrar using outbound (I assume connect-reuse would be used instead), > then there is no reason for the registrar to place Supported outbound in > the > REGISTER response. This could be left for the edge proxy to insert. If it > is > felt inappropriate for a proxy to insert a Supported header tag, then > perhaps there is something else it can insert. This would seem much more > reliable than depending on configuration. > > John > >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: 29 March 2006 20:36 >> To: Elwell, John; sip@ietf.org >> Subject: Re: [Sip] outbound: summary of issues >> >> John, >> >> see inline >> >> >> ----- Original Message ----- >> From: "Elwell, John" >> To: "Jeroen van Bemmel" ; >> Sent: Wednesday, March 29, 2006 9:23 PM >> Subject: RE: [Sip] outbound: summary of issues >> >> >> > >> > >> >> -----Original Message----- >> >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> >> Sent: 29 March 2006 19:49 >> >> To: sip@ietf.org >> >> Subject: [Sip] outbound: summary of issues >> >> >> >> An attempt to summarize issues identified so far, in the form >> >> of closed questions: >> >> >> >> 1. Configuration of outbound proxies - desire to avoid manual >> >> configuration at the UAC. Do we agree that we want this? >> >> 1a If yes, in the outbound draft or as a separate draft? >> >> 2. Detection of outbound/keepalive support - desire for >> >> dynamic discovery of support instead of (or perhaps in >> >> addition to) static configuration (the current keepalive=stun >> >> flag). Do we agree that we want this? (several options have >> >> been discussed) >> > [JRE] I can't recall what was wrong with just an option tag in the >> > Supported >> > header of the REGISTER response. >> >> That would indicate that the registrar supports outbound, but >> says nothing >> about the edge proxy. The risk is that the UAC starts poking >> it with STUN >> requests while it is not supported. >> >> An outbound proxy URI with keepalive=stun would indicate >> proxy support, but >> that would only be an informed guess - there is the possibility for >> misconfiguration. To avoid this, it would be good if the proxy would >> actively indicate that it supports outbound (in particular STUN). >> >> Jeroen >> >> > >> > 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 Wed Mar 29 17:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOijd-0003XJ-S4; Wed, 29 Mar 2006 17:01:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOijc-0003XE-Um for sip@ietf.org; Wed, 29 Mar 2006 17:01:48 -0500 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 1FOijc-0002sB-AW for sip@ietf.org; Wed, 29 Mar 2006 17:01:48 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 29 Mar 2006 14:01:47 -0800 X-IronPort-AV: i="4.03,144,1141632000"; d="scan'208"; a="318298095:sNHT47272736" 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 k2TM1kw7000682; Wed, 29 Mar 2006 14:01:47 -0800 (PST) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 14:01:46 -0800 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-cao-sip-response-identity-00.txt Date: Wed, 29 Mar 2006 14:01:45 -0800 Message-ID: <5F16CF3DBBC7EE45BF6E136F13F5CFEA01E62A37@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-cao-sip-response-identity-00.txt Thread-Index: AcZTbza767F5my2CR2aqJG0DLj8x0AABZI1Q From: "Feng Cao \(fcao\)" To: X-OriginalArrivalTime: 29 Mar 2006 22:01:46.0942 (UTC) FILETIME=[5F787DE0:01C6537C] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: sip@ietf.org, Francois Audet , "Drage, Keith \(Keith\)" , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Shilda, Instead of mingling several issues related to response identity and response security, I hope that the further discussion may address each separate issue clearly and/or their relationship. I had tried to summarize the issues (and some relationships among them) and sent to the list. They were pasted here again: Q1. provide the mechanism to disclose response identity (and integrity protection) in all call scenarios. Q2. provide the secure authentication and authorization mechanism for response Q3. provide the mechanism to understand why that responder is reached. Q1 is to present response identity and integrity protection on it. From some feedbacks in this list and offline discussions, there are some needs to provide the solution to Q1. Of course, any input is welcome to refine these needs and the related useful scenarios. If the security about response identity (and response itself) is concerned, Q2 should be answered and be included into WG deliverable. The solution to Q3 is also helpful if WG wants to cover it. =20 I disagree on your statement about connected-id. The three scenarios mentioned for response identity cannot be efficiently covered by connected-id, as it is too late. In addition, I have doubts about imposing pre-condition during call setup. For example, the originator may not know whether the responder can provide connected-id (such as backward compatible). It is not my intention to bring up more issues in this thread, but it is worth noting the different needs which can be covered by response identity only. =20 Regards, --Feng -----Original Message----- From: Shida Schubert [mailto:shida@ntt-at.com]=20 Sent: Wednesday, March 29, 2006 12:27 PM To: Feng Cao (fcao) Cc: Francois Audet; Vijay K. Gurbani; sip@ietf.org; Drage,Keith (Keith) Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt Hi Feng; I don't really know how much of the problem can really be solved here, and I would like to know because it seems like I am just not getting it. Proxy non-adjacent to UA sending a response identity alone does not seem to provide enough information that the responding proxy really is a valid proxy, meaning that it's not a MitM. Unless you can show that the request indeed ended up at the proxy responding with the identity, response-identity alone seems insufficient, may be useful but insufficient. I personally think H-I, if signaling path is secured(sips or TLS proxy chain) may be sufficient. Regarding your second issue, what kind of non-dialog session might find the response-identity useful? I just can't seem to imagine a use-case that's sensible and I am very interested in hearing its usage. Lastly, I thought about the last issue you brought up about identity spoofing and I do see some value in it, as you can probably track the malicious user who made a plank call more easily if identity header is available. I guess if identity header is available you are able to inquire or sue the responsible domain. But connected-identity provides the same benefit by providing identity header in the request in opposite direction simply at a different stage of the call. If it's all about providing this at the call setup time because you don't want to exchange any media with the malicious responder, then you can define a pre-condition where both users need to provide an identity, in which case, media exchange won't start until connected-identity is provided through an UPDATE or re-INVITE, upon which UAC or calling proxy can apply its local policy using the response-identity provided and decide whether to proceed with the media exchange etc. Regards Shida Feng Cao (fcao) wrote: > > There are some needs for providing response identity and we had listed > them in the meeting. So far, one of them had received a lot of support > from both some offline discussions and the comments in this list, it=20 > is to "reveal the proxy's identity as the responder for some response=20 > codes, such as provisional, redirect and failure responses." > > The other two needs listed in the meeting are pasted here again for=20 > more feedback. One is to "disclose the response identity for=20 > non-dialog session", the other is to "prevent the identity spoofing as > early as possible". > > > ---------------------------------------------------------------------- > -- > *From:* Francois Audet [mailto:audet@nortel.com] > *Sent:* Wednesday, March 29, 2006 8:55 AM > *To:* Vijay K. Gurbani > *Cc:* 'sip@ietf.org'; Drage,Keith (Keith) > *Subject:* Re: [Sip] draft-cao-sip-response-identity-00.txt > > My take is that there is no agreement that there is a compelling=20 > reason to do response identity. That's the main issue. > > I agree that connected-identity on the other is non-controversial. > > Vijay K. Gurbani wrote: >> Drage, Keith (Keith) wrote: >> =20 >>> (as chair) >>> =20 >> [...] >> =20 >>> We do not plan to make any decision about the documentation of=20 >>> draft-cao-sip-response-identity-00.txt until there is some consensus >>> on the mechanisms proposed and support for moving forward. At the=20 >>> moment there have been no posts in favour or against achieving that=20 >>> consensus, and at the moment all we can assume is that there is no=20 >>> support for solving this problem at all. >>> =20 >> >> Keith: Is it conceivable to break the milestone into two? One=20 >> provides solution for knowing who I have connected with=20 >> (connected-identity), and the other provides the identity of the=20 >> intermediary or endpoint who issued provisional and non-2xx responses >> (could use response- identity as a starting point). >> >> I don't think there is much debate over connected-identity; the WG=20 >> agrees that this is the way forward on knowing authoritatively who a=20 >> UAC is connected to. connected-identity, IIRC, only kicks in when=20 >> the UAS agrees to session establishment (i.e., a 200 OK is sent out). >> But what about user agents and intermediaries that issue non-2xx=20 >> responses? >> >> Ostensibly, there could be some advantage in knowing that an=20 >> intermediary who issued a 3xx is not sending me on a wild goose=20 >> chase. TLS could be one way to ascertain the identity of the=20 >> intermediary if I am connected directly (i.e., next hop) to the=20 >> responder. But what about a chain of TLS proxies where the=20 >> responding proxy or UAS is a few hops downstream? In that case,=20 >> response-identity allows the receiver to know who issued a final response. >> >> So, does the WG see a need to provide a solution for response=20 >> identity, which could be defined as the identity of an intermediary=20 >> issuing a 1xx response or a non-2xx response, or the identity of an=20 >> endpoint issuing a non-2xx response? If so, then maybe the following >> can be candidate proposals: >> >> 1) response-identity. >> 2) P-A-I applied to responses. >> 3) H-I header (I don't think this works since in H-I it is the >> UAC or the proxy that sends a request downstream that adds a >> H-I header. A UAS echoes the H-I headers, but does not add >> them pre-emptively, AFAIK). >> 4) Others...? >> >> Thanks, >> >> - vijay >> =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=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 Wed Mar 29 17:58:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOjaU-0005Hd-Ou; Wed, 29 Mar 2006 17:56:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOjaT-0005HY-HJ for sip@ietf.org; Wed, 29 Mar 2006 17:56:25 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOjaQ-0004W1-Vo for sip@ietf.org; Wed, 29 Mar 2006 17:56:25 -0500 Received: from s010600095b9792b5.vc.shawcable.net ([70.79.6.118] helo=[192.168.0.101]) by dns.aliantmedia.net with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.52) id 1FOjaO-0007iz-N5; Wed, 29 Mar 2006 16:56:21 -0600 Message-ID: <442B1091.9030109@ntt-at.com> Date: Wed, 29 Mar 2006 14:56:17 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Feng Cao (fcao)" Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt References: <5F16CF3DBBC7EE45BF6E136F13F5CFEA01E62A37@xmb-sjc-224.amer.cisco.com> In-Reply-To: <5F16CF3DBBC7EE45BF6E136F13F5CFEA01E62A37@xmb-sjc-224.amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: sip@ietf.org 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 Feng; I agree that integrity protection in response would be a "nice to have" feature. Few more questions.. How is Q1 satisfied without Q2, I tend to think that Q2 needs to be satisfied somehow(Not necessary an authentication of response but authentication of the responder, possibly prior to responding..) in order to provide somewhat of a reliable response identity(Q1). What do you mean by connected-id being too late? Sure, it's nice to see who is responding but who is responding in the call-establishment phase, and who you actually end up talking to might be different. What do you want to get out of getting a responder-id in call-establishment phase? Do you want to prioritize callee that supports response-id? BTW I am not opposing to the work here, just want to know more about what it's trying to address. Regards Shida Feng Cao (fcao) wrote: > Hi Shilda, > > Instead of mingling several issues related to response identity and > response security, I hope that the further discussion may address each > separate issue clearly and/or their relationship. I had tried to > summarize the issues (and some relationships among them) and sent to the > list. They were pasted here again: > > Q1. provide the mechanism to disclose response identity > (and integrity protection) in all call scenarios. > Q2. provide the secure authentication and authorization mechanism > for response > Q3. provide the mechanism to understand why that responder is reached. > > Q1 is to present response identity and integrity protection on it. From > some feedbacks in this list and offline discussions, there are some > needs to provide the solution to Q1. Of course, any input is welcome to > refine these needs and the related useful scenarios. > > If the security about response identity (and response itself) is > concerned, Q2 should be answered and be included into WG deliverable. > The solution to Q3 is also helpful if WG wants to cover it. > > I disagree on your statement about connected-id. The three scenarios > mentioned for response identity cannot be efficiently covered by > connected-id, as it is too late. In addition, I have doubts about > imposing pre-condition during call setup. For example, the originator > may not know whether the responder can provide connected-id (such as > backward compatible). It is not my intention to bring up more issues in > this thread, but it is worth noting the different needs which can be > covered by response identity only. > > Regards, > > --Feng > > > > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: Wednesday, March 29, 2006 12:27 PM > To: Feng Cao (fcao) > Cc: Francois Audet; Vijay K. Gurbani; sip@ietf.org; Drage,Keith (Keith) > Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt > > > Hi Feng; > > I don't really know how much of the problem can really be solved here, > and I would like to know because it seems like I am just not getting it. > > Proxy non-adjacent to UA sending a response identity alone does not seem > to provide enough information that the responding proxy really is a > valid proxy, meaning that it's not a MitM. Unless you can show that the > request indeed ended up at the proxy responding with the identity, > response-identity alone seems insufficient, may be useful but > insufficient. > > I personally think H-I, if signaling path is secured(sips or TLS proxy > chain) > may be sufficient. > > Regarding your second issue, what kind of non-dialog session might find > the response-identity useful? I just can't seem to imagine a use-case > that's sensible and I am very interested in hearing its usage. > > Lastly, I thought about the last issue you brought up about identity > spoofing and I do see some value in it, as you can probably track the > malicious user who made a plank call more easily if identity header is > available. I guess if identity header is available you are able to > inquire or sue the responsible domain. > > But connected-identity provides the same benefit by providing identity > header in the request in opposite direction simply at a different stage > of the call. > > If it's all about providing this at the call setup time because you > don't want to exchange any media with the malicious responder, then you > can define a pre-condition where both users need to provide an identity, > in which case, media exchange won't start until connected-identity is > provided through an UPDATE or re-INVITE, upon which UAC or calling proxy > can apply its local policy using the response-identity provided and > decide whether to proceed with the media exchange etc. > > Regards > Shida > > Feng Cao (fcao) wrote: > >> There are some needs for providing response identity and we had listed >> > > >> them in the meeting. So far, one of them had received a lot of support >> > > >> from both some offline discussions and the comments in this list, it >> is to "reveal the proxy's identity as the responder for some response >> codes, such as provisional, redirect and failure responses." >> >> The other two needs listed in the meeting are pasted here again for >> more feedback. One is to "disclose the response identity for >> non-dialog session", the other is to "prevent the identity spoofing as >> > > >> early as possible". >> >> >> ---------------------------------------------------------------------- >> -- >> *From:* Francois Audet [mailto:audet@nortel.com] >> *Sent:* Wednesday, March 29, 2006 8:55 AM >> *To:* Vijay K. Gurbani >> *Cc:* 'sip@ietf.org'; Drage,Keith (Keith) >> *Subject:* Re: [Sip] draft-cao-sip-response-identity-00.txt >> >> My take is that there is no agreement that there is a compelling >> reason to do response identity. That's the main issue. >> >> I agree that connected-identity on the other is non-controversial. >> >> Vijay K. Gurbani wrote: >> >>> Drage, Keith (Keith) wrote: >>> >>> >>>> (as chair) >>>> >>>> >>> [...] >>> >>> >>>> We do not plan to make any decision about the documentation of >>>> draft-cao-sip-response-identity-00.txt until there is some consensus >>>> > > >>>> on the mechanisms proposed and support for moving forward. At the >>>> moment there have been no posts in favour or against achieving that >>>> consensus, and at the moment all we can assume is that there is no >>>> support for solving this problem at all. >>>> >>>> >>> Keith: Is it conceivable to break the milestone into two? One >>> provides solution for knowing who I have connected with >>> (connected-identity), and the other provides the identity of the >>> intermediary or endpoint who issued provisional and non-2xx responses >>> > > >>> (could use response- identity as a starting point). >>> >>> I don't think there is much debate over connected-identity; the WG >>> agrees that this is the way forward on knowing authoritatively who a >>> UAC is connected to. connected-identity, IIRC, only kicks in when >>> the UAS agrees to session establishment (i.e., a 200 OK is sent out). >>> > > >>> But what about user agents and intermediaries that issue non-2xx >>> responses? >>> >>> Ostensibly, there could be some advantage in knowing that an >>> intermediary who issued a 3xx is not sending me on a wild goose >>> chase. TLS could be one way to ascertain the identity of the >>> intermediary if I am connected directly (i.e., next hop) to the >>> responder. But what about a chain of TLS proxies where the >>> responding proxy or UAS is a few hops downstream? In that case, >>> response-identity allows the receiver to know who issued a final >>> > response. > >>> So, does the WG see a need to provide a solution for response >>> identity, which could be defined as the identity of an intermediary >>> issuing a 1xx response or a non-2xx response, or the identity of an >>> endpoint issuing a non-2xx response? If so, then maybe the following >>> > > >>> can be candidate proposals: >>> >>> 1) response-identity. >>> 2) P-A-I applied to responses. >>> 3) H-I header (I don't think this works since in H-I it is the >>> UAC or the proxy that sends a request downstream that adds a >>> H-I header. A UAS echoes the H-I headers, but does not add >>> them pre-emptively, AFAIK). >>> 4) Others...? >>> >>> 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 >>> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 20:32:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOlzU-0003gV-R4; Wed, 29 Mar 2006 20:30:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOlzT-0003g1-PG for sip@ietf.org; Wed, 29 Mar 2006 20:30:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOlzS-0005kS-Ff for sip@ietf.org; Wed, 29 Mar 2006 20:30:23 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2006 17:30:21 -0800 X-IronPort-AV: i="4.03,145,1141632000"; d="scan'208"; a="1790085416:sNHT31555982" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2U1UL1j009636; Wed, 29 Mar 2006 17:30:21 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Mar 2006 01:30:20 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 29 Mar 2006 17:30:20 -0800 Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt From: Cullen Jennings To: Aki Niemi , Dean Willis Message-ID: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZTmYHVwFLGvr+MEdqPogARJEEJ/A== In-Reply-To: <44241E2C.2030709@nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "sip@ietf.org" , 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 Clearly discovering the proxy set is a separable problem from what to do with it. As we agreed in the meeting, I would rather have these is separate documents since we can move forward with the what you do with it now and solve the many possible way beyond configuration how you might find it later. I will point out that for most deployed SIP UA, the AOR is supplied by some configuration system and not by the end user typing it in so there are *some* systems that can work with configuration. Cullen wrote: > > > ext Dean Willis wrote: >> Possible alternatives: >> >> 1) Deducing from the proxy URL that it supports Outbound. This >> potentially works with DNS, DHCP, and configured discovery, but might >> just be a little too weird with our existing syntax and conventions. >> >> 2) Using a different service record in DNS, which works for DNS but not >> DHCP or configured use cases, I think. >> >> We have any other techniques that have been proposed here that I have >> missed? > > 3) The proxy corresponding to the entry in the SRV record of a domain, > inspects the Supported of an incoming request for the "outbound" token, > and if it exists, redirects the request either with a new 3xx "connect > to all of these", or use 300 with new bits that indicate this new semantic. > > 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 From sip-bounces@ietf.org Wed Mar 29 20:52:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOmJA-0005wx-IS; Wed, 29 Mar 2006 20:50:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOmJ9-0005ws-4P for sip@ietf.org; Wed, 29 Mar 2006 20:50:43 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOmJ7-0006ji-SW for sip@ietf.org; Wed, 29 Mar 2006 20:50:43 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2006 17:50:41 -0800 X-IronPort-AV: i="4.03,145,1141632000"; d="scan'208"; a="1790091376:sNHT32088356" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2U1of1j017074; Wed, 29 Mar 2006 17:50:41 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Mar 2006 01:50:40 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 29 Mar 2006 17:50:40 -0800 Subject: Re: [Sip] How to indicate during proxy discovery that a proxy supports"outbound" From: Cullen Jennings To: Jeroen van Bemmel , Dean Willis , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] How to indicate during proxy discovery that a proxy supports"outbound" Thread-Index: AcZTnFkCl4B0kL+PEdqPogARJEEJ/A== In-Reply-To: <002201c65056$80ac1a90$31713b51@BEMBUSTER> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: 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 On 3/25/06 1:53 PM, "Jeroen van Bemmel" wrote: > Could you explain why it is needed that the UA knows whether the proxy > supports outbound before sending its REGISTER request? So that we don't send things to the proxy that it does not understand. Some people did not care about this - some felt strongly about it. Some pointed out that the proxy might black list a client that seemed to be "attacking it" with bogus packets. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 29 21:09:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOmZB-00079f-Fq; Wed, 29 Mar 2006 21:07:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOmZ9-00076g-NZ for sip@ietf.org; Wed, 29 Mar 2006 21:07:15 -0500 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 1FOmZ8-0007GE-F4 for sip@ietf.org; Wed, 29 Mar 2006 21:07:15 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2006 18:07:13 -0800 X-IronPort-AV: i="4.03,145,1141632000"; d="scan'208"; a="421260513:sNHT30551892" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2U27DGv027314; Wed, 29 Mar 2006 18:07:13 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Mar 2006 02:07:13 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 29 Mar 2006 18:07:12 -0800 Subject: Re: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 From: Cullen Jennings To: Shida Schubert , John Elwell Message-ID: Thread-Topic: [Sip] draft-cao-sip-response-identity-00 and draft-elwell-sip -connected-identity-01 Thread-Index: AcZTnqhK5vFXZr+REdqPogARJEEJ/A== In-Reply-To: <44216A05.6080904@ntt-at.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 2.7 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Me too. On 3/22/06 9:15 AM, "Shida Schubert" wrote: > > I agree with John with the consensus of the room. > > Regards > Shida Schubert > > Elwell, John wrote: >> Rocky, >> >> The connected-identity draft is not a subset of the response identity draft. >> The response identity draft cannot be used to indicate a change of party >> mid-dialog. >> >> I don't think we can merge them. There was no consensus on the response >> identity draft. The following views have been expressed: >> - that it does not provide any benefit; >> - that the response identity problem cannot be solved, and that the approach >> taken in the connected-identity draft is the best that can be achieved. >> >> If and when there is consensus on a response identity solution, then we >> could consider whether it would be appropriate to merge the two, but that is >> not the case at present. >> >> 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 Wed Mar 29 21:09:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOmYz-0006vk-SO; Wed, 29 Mar 2006 21:07:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOmYy-0006sV-HQ for sip@ietf.org; Wed, 29 Mar 2006 21:07:04 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOmYw-0007G4-31 for sip@ietf.org; Wed, 29 Mar 2006 21:07:04 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 29 Mar 2006 18:07:01 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2U271w1012447; Wed, 29 Mar 2006 18:07:01 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Mar 2006 02:07:01 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 29 Mar 2006 18:07:00 -0800 Subject: Re: [Sip] draft-cao-sip-response-identity-00.txt From: Cullen Jennings To: Dean Willis , Francois Audet Message-ID: Thread-Topic: [Sip] draft-cao-sip-response-identity-00.txt Thread-Index: AcZTnqEi39gdor+REdqPogARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 3/29/06 10:04 AM, "Dean Willis" wrote: > I propose that we amend the charter to show a midsummer deliverable > for connected identity, and use the Elwell draft as a basis for this > deliverable. With my individual contributor hat on ...Sounds reasonable to me - we likely want to get crisp about the difference between mid dialog identity and changing the identity in a dialog forming request. > > Then we add a later milestone to deliver a decision on whether we > will be adding a new milestone for response identity. And I hope we have some discussion about what problem this solves before adding 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 Mar 30 01:10:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOqK9-0006d1-32; Thu, 30 Mar 2006 01:08:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOqK6-0006cw-FT for sip@ietf.org; Thu, 30 Mar 2006 01:07:58 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOqK5-0000G5-1Y for sip@ietf.org; Thu, 30 Mar 2006 01:07:58 -0500 Received: (qmail 31860 invoked by uid 0); 30 Mar 2006 06:07:56 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 30 Mar 2006 06:07:56 -0000 Message-ID: <002601c653c0$4880e1b0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" , "Dean Willis" , References: Subject: Re: [Sip] How to indicate during proxy discovery that a proxy supports"outbound" Date: Thu, 30 Mar 2006 08:07:53 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 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 > On 3/25/06 1:53 PM, "Jeroen van Bemmel" wrote: > >> Could you explain why it is needed that the UA knows whether the proxy >> supports outbound before sending its REGISTER request? > > So that we don't send things to the proxy that it does not understand. > Some > people did not care about this - some felt strongly about it. Some pointed > out that the proxy might black list a client that seemed to be "attacking > it" with bogus packets. The people that feel strongly about this could add 'Require: outbound' to their request. Implementations that would blacklist such clients would be considered broken. An alternative would perhaps be to depend on an authentication challenge: first send a normal REGISTER, challenge, respond to the challenge and if Supported: outbound is there modify the request as needed. Not common practice though... 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 Mar 30 01:52:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOqyR-0006CI-QM; Thu, 30 Mar 2006 01:49:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOqy9-0005tY-Hp for sip@ietf.org; Thu, 30 Mar 2006 01:49:21 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOqw5-00026K-0R for sip@ietf.org; Thu, 30 Mar 2006 01:47:14 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FOqw1-0000a8-7D; Thu, 30 Mar 2006 09:47:09 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17451.32493.130932.496483@harjus.tutpro.com> Date: Thu, 30 Mar 2006 09:47:09 +0300 To: Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: References: <44241E2C.2030709@nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "sip@ietf.org" , Aki Niemi , 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 Cullen Jennings writes: > As we agreed in the meeting, I would rather have these is separate > documents since we can move forward with the what you do with it now and > solve the many possible way beyond configuration how you might find it > later. it is fine to have a separate document describing how SIP UA finds outbound-proxy-set, but that separate document MUST be referenced in the outbound I-D in the same way as rfc3263 is referenced by rfc3261. there is no point to publish a document where the only standards based way to configure outbound-proxy-set is manually, because no regular user is able to do it correctly. -- 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 Thu Mar 30 01:52:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOqzE-0006tG-1U; Thu, 30 Mar 2006 01:50:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOqzB-0006pw-Fo for sip@ietf.org; Thu, 30 Mar 2006 01:50:25 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOqzA-0002UL-Qr for sip@ietf.org; Thu, 30 Mar 2006 01:50:25 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWX00301HOWA6@siemenscomms.co.uk> for sip@ietf.org; Thu, 30 Mar 2006 07:50:56 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWX00225HOW0J@siemenscomms.co.uk>; Thu, 30 Mar 2006 07:50:56 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Mar 2006 07:50:23 +0100 Content-return: allowed Date: Thu, 30 Mar 2006 07:49:15 +0100 From: "Elwell, John" Subject: RE: [Sip] outbound: summary of issues To: Jeroen van Bemmel , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708896ED9@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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 Jeroen, I think it is important that the mechanism used by the UA to determine support for outbound be independent of whether there is a proxy present between the UA and the Registrar. The UA should not have to care about this. As I understand it, the Path header would be used only if there is an edge proxy present, so if the Path header were used to indicate support for outbound, then some other mechanism would be needed for when there is no proxy. Personally I prefer to use Supported, even if by manipulating the outbound tag at the proxy it violates normal use of Supported. John > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 29 March 2006 22:13 > To: Elwell, John; sip@ietf.org > Subject: Re: [Sip] outbound: summary of issues > > John, > > Yes, this is what one thread of the discussion was about, and > you seem to > agree with #2 below > > Proxies inserting Supported: I think that would indeed be > inappropriate as > you indicate. > What about feature tags a la callerprefs (RFC3841) in Path > and Record-Route > headers? > > Path: ;extensions="outbound" > > This would imply that proxies cannot indicate extensions without > Record-Routing, but since the information is only relevant > when the proxy > stays in the path for next requests, this somehow feels > appropriate to me > > Regards, > > jeroen > > ----- Original Message ----- > From: "Elwell, John" > To: "Jeroen van Bemmel" ; > Sent: Wednesday, March 29, 2006 10:05 PM > Subject: RE: [Sip] outbound: summary of issues > > > > Jeroen, > > > > Thanks for your explanation. However, could we not limit > use of Supported > > outbound to the edge proxy. Since an edge proxy would not > connect to the > > registrar using outbound (I assume connect-reuse would be > used instead), > > then there is no reason for the registrar to place > Supported outbound in > > the > > REGISTER response. This could be left for the edge proxy to > insert. If it > > is > > felt inappropriate for a proxy to insert a Supported header > tag, then > > perhaps there is something else it can insert. This would > seem much more > > reliable than depending on configuration. > > > > John > > > >> -----Original Message----- > >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >> Sent: 29 March 2006 20:36 > >> To: Elwell, John; sip@ietf.org > >> Subject: Re: [Sip] outbound: summary of issues > >> > >> John, > >> > >> see inline > >> > >> > >> ----- Original Message ----- > >> From: "Elwell, John" > >> To: "Jeroen van Bemmel" ; > >> Sent: Wednesday, March 29, 2006 9:23 PM > >> Subject: RE: [Sip] outbound: summary of issues > >> > >> > >> > > >> > > >> >> -----Original Message----- > >> >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >> >> Sent: 29 March 2006 19:49 > >> >> To: sip@ietf.org > >> >> Subject: [Sip] outbound: summary of issues > >> >> > >> >> An attempt to summarize issues identified so far, in the form > >> >> of closed questions: > >> >> > >> >> 1. Configuration of outbound proxies - desire to avoid manual > >> >> configuration at the UAC. Do we agree that we want this? > >> >> 1a If yes, in the outbound draft or as a separate draft? > >> >> 2. Detection of outbound/keepalive support - desire for > >> >> dynamic discovery of support instead of (or perhaps in > >> >> addition to) static configuration (the current keepalive=stun > >> >> flag). Do we agree that we want this? (several options have > >> >> been discussed) > >> > [JRE] I can't recall what was wrong with just an option > tag in the > >> > Supported > >> > header of the REGISTER response. > >> > >> That would indicate that the registrar supports outbound, but > >> says nothing > >> about the edge proxy. The risk is that the UAC starts poking > >> it with STUN > >> requests while it is not supported. > >> > >> An outbound proxy URI with keepalive=stun would indicate > >> proxy support, but > >> that would only be an informed guess - there is the possibility for > >> misconfiguration. To avoid this, it would be good if the > proxy would > >> actively indicate that it supports outbound (in particular STUN). > >> > >> Jeroen > >> > >> > > >> > 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 Thu Mar 30 03:39:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOsfC-00014b-AB; Thu, 30 Mar 2006 03:37:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOsfA-00013x-3r for sip@ietf.org; Thu, 30 Mar 2006 03:37:52 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOsf4-0008Bv-Lm for sip@ietf.org; Thu, 30 Mar 2006 03:37:51 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D115B4F0002; Thu, 30 Mar 2006 10:37:45 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 10:37:45 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 10:37: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound: summary of issues Date: Thu, 30 Mar 2006 10:37:45 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C18@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound: summary of issues Thread-Index: AcZTxl2sEbSF0qJ3R9+CAdZ6G0UBuQADcVaQ From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Jeroen van Bemmel" , X-OriginalArrivalTime: 30 Mar 2006 08:37:45.0411 (UTC) FILETIME=[37B0C930:01C653D5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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, Will there be some other kind of information, related to outbound, that we need to transport? Anything related to the NAT keep-alive (timer values etc)? Since we are defining a new extension, we could also define a new header, which could carry the information. OR, as I wrote in another mail, do we want a more generic mechanism how nodes can indicate support for extensions and capabilities (other than outbound)?=20 Because, in future there may be an extension which requires similar knowledge as now... Of course, one option is to modify the Supported header. But, then again, would it really work? Assume the registrar indicates that it supports outbound, but the proxy(s) between the UA and the registrar do not. The proxy(x), however, still insert a Path header, which means they will be in the path. But, how does the UA know which of the proxies (including the registrar) really supports outbound? Regards, Christer=20 =20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: 30. maaliskuuta 2006 9:49 To: Jeroen van Bemmel; sip@ietf.org Subject: RE: [Sip] outbound: summary of issues Jeroen, I think it is important that the mechanism used by the UA to determine support for outbound be independent of whether there is a proxy present between the UA and the Registrar. The UA should not have to care about this. As I understand it, the Path header would be used only if there is an edge proxy present, so if the Path header were used to indicate support for outbound, then some other mechanism would be needed for when there is no proxy. Personally I prefer to use Supported, even if by manipulating the outbound tag at the proxy it violates normal use of Supported. John > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 29 March 2006 22:13 > To: Elwell, John; sip@ietf.org > Subject: Re: [Sip] outbound: summary of issues >=20 > John, >=20 > Yes, this is what one thread of the discussion was about, and you seem > to agree with #2 below >=20 > Proxies inserting Supported: I think that would indeed be=20 > inappropriate as you indicate. > What about feature tags a la callerprefs (RFC3841) in Path and=20 > Record-Route headers? >=20 > Path: ;extensions=3D"outbound" >=20 > This would imply that proxies cannot indicate extensions without=20 > Record-Routing, but since the information is only relevant when the=20 > proxy stays in the path for next requests, this somehow feels=20 > appropriate to me >=20 > Regards, >=20 > jeroen >=20 > ----- Original Message ----- > From: "Elwell, John" > To: "Jeroen van Bemmel" ; > Sent: Wednesday, March 29, 2006 10:05 PM > Subject: RE: [Sip] outbound: summary of issues >=20 >=20 > > Jeroen, > > > > Thanks for your explanation. However, could we not limit > use of Supported > > outbound to the edge proxy. Since an edge proxy would not > connect to the > > registrar using outbound (I assume connect-reuse would be > used instead), > > then there is no reason for the registrar to place > Supported outbound in > > the > > REGISTER response. This could be left for the edge proxy to > insert. If it > > is > > felt inappropriate for a proxy to insert a Supported header > tag, then > > perhaps there is something else it can insert. This would > seem much more > > reliable than depending on configuration. > > > > John > > > >> -----Original Message----- > >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >> Sent: 29 March 2006 20:36 > >> To: Elwell, John; sip@ietf.org > >> Subject: Re: [Sip] outbound: summary of issues > >> > >> John, > >> > >> see inline > >> > >> > >> ----- Original Message ----- > >> From: "Elwell, John" > >> To: "Jeroen van Bemmel" ; > >> Sent: Wednesday, March 29, 2006 9:23 PM > >> Subject: RE: [Sip] outbound: summary of issues > >> > >> > >> > > >> > > >> >> -----Original Message----- > >> >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >> >> Sent: 29 March 2006 19:49 > >> >> To: sip@ietf.org > >> >> Subject: [Sip] outbound: summary of issues > >> >> > >> >> An attempt to summarize issues identified so far, in the form of > >> >> closed questions: > >> >> > >> >> 1. Configuration of outbound proxies - desire to avoid manual=20 > >> >> configuration at the UAC. Do we agree that we want this? > >> >> 1a If yes, in the outbound draft or as a separate draft? > >> >> 2. Detection of outbound/keepalive support - desire for dynamic=20 > >> >> discovery of support instead of (or perhaps in addition to)=20 > >> >> static configuration (the current keepalive=3Dstun flag). Do we=20 > >> >> agree that we want this? (several options have been discussed) > >> > [JRE] I can't recall what was wrong with just an option > tag in the > >> > Supported > >> > header of the REGISTER response. > >> > >> That would indicate that the registrar supports outbound, but says=20 > >> nothing about the edge proxy. The risk is that the UAC starts=20 > >> poking it with STUN requests while it is not supported. > >> > >> An outbound proxy URI with keepalive=3Dstun would indicate proxy=20 > >> support, but that would only be an informed guess - there is the=20 > >> possibility for misconfiguration. To avoid this, it would be good=20 > >> if the > proxy would > >> actively indicate that it supports outbound (in particular STUN). > >> > >> Jeroen > >> > >> > > >> > John > >>=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 Mar 30 03:46:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOsly-0002vc-W5; Thu, 30 Mar 2006 03:44:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOslx-0002uG-Qg for sip@ietf.org; Thu, 30 Mar 2006 03:44:53 -0500 Received: from smtp13.clb.oleane.net ([213.56.31.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOslx-0008OJ-EN for sip@ietf.org; Thu, 30 Mar 2006 03:44:53 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp13.clb.oleane.net with ESMTP id k2U8ifr2027563 for ; Thu, 30 Mar 2006 10:44:51 +0200 Message-Id: <200603300844.k2U8ifr2027563@smtp13.clb.oleane.net> From: "Chantal Ladouce" To: Date: Thu, 30 Mar 2006 10:44:00 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZT1hbS/fPf5PQZRsydnk0Mo2u0jg== X-Spam-Score: 0.2 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Subject: [Sip] Wireless/WiFi Convergence Conference - 16 to 19 May 2006 - Paris - France X-BeenThere: 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="===============0190611366==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0190611366== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0268_01C653E6.DAB61F70" This is a multi-part message in MIME format. ------=_NextPart_000_0268_01C653E6.DAB61F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Wireless/WiFi Convergence Conference - 16 to 19 May 2006 - Paris - France Last days to benefit from the Early Bird Offer! Register before Monday the 3rd of April and save 10 % on the Registration Fees. For more info and to register, please visit: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006terms.htm ------=_NextPart_000_0268_01C653E6.DAB61F70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wireless/Wi= Fi Convergence Conference - 16 to 19 May 2006 - Paris - France

 =

Last days = to benefit from the Early Bird Offer!

 =

Register before Monday the 3rd of April and save = 10 % on the Registration Fees.

For more info and to register, please = visit:

http://www.upperside.fr/wirelessconvergence2006/wwconvergence= 2006terms.htm

 

------=_NextPart_000_0268_01C653E6.DAB61F70-- --===============0190611366== 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 --===============0190611366==-- From sip-bounces@ietf.org Thu Mar 30 04:18:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtGw-0008Bo-1n; Thu, 30 Mar 2006 04:16:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtGu-0008Bg-2u for sip@ietf.org; Thu, 30 Mar 2006 04:16:52 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOtGt-0001EC-J5 for sip@ietf.org; Thu, 30 Mar 2006 04:16:52 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWX00I01OGZA4@siemenscomms.co.uk> for sip@ietf.org; Thu, 30 Mar 2006 10:17:23 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWX00H27OGYIZ@siemenscomms.co.uk>; Thu, 30 Mar 2006 10:17:22 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Mar 2006 10:16:49 +0100 Content-return: allowed Date: Thu, 30 Mar 2006 10:16:37 +0100 From: "Elwell, John" Subject: RE: [Sip] outbound: summary of issues To: "Christer Holmberg (JO/LMF)" , Jeroen van Bemmel , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670889713A@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 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 Christian, Yes, you are right, Supported will not work, because an edge proxy that doesn't support it cannot be expected to remove it! It seems that a new header might be best. John > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 30 March 2006 09:38 > To: Elwell, John; Jeroen van Bemmel; sip@ietf.org > Subject: RE: [Sip] outbound: summary of issues > > > Hi, > > Will there be some other kind of information, related to > outbound, that > we need to transport? Anything related to the NAT keep-alive (timer > values etc)? > > Since we are defining a new extension, we could also define a new > header, which could carry the information. > > OR, as I wrote in another mail, do we want a more generic > mechanism how > nodes can indicate support for extensions and capabilities (other than > outbound)? > > Because, in future there may be an extension which requires similar > knowledge as now... > > Of course, one option is to modify the Supported header. But, then > again, would it really work? Assume the registrar indicates that it > supports outbound, but the proxy(s) between the UA and the > registrar do > not. The proxy(x), however, still insert a Path header, which > means they > will be in the path. But, how does the UA know which of the proxies > (including the registrar) really supports outbound? > > Regards, > > Christer > > > > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 30. maaliskuuta 2006 9:49 > To: Jeroen van Bemmel; sip@ietf.org > Subject: RE: [Sip] outbound: summary of issues > > Jeroen, > > I think it is important that the mechanism used by the UA to determine > support for outbound be independent of whether there is a > proxy present > between the UA and the Registrar. The UA should not have to care about > this. > As I understand it, the Path header would be used only if there is an > edge proxy present, so if the Path header were used to > indicate support > for outbound, then some other mechanism would be needed for when there > is no proxy. > > Personally I prefer to use Supported, even if by manipulating the > outbound tag at the proxy it violates normal use of Supported. > > John > > > -----Original Message----- > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > Sent: 29 March 2006 22:13 > > To: Elwell, John; sip@ietf.org > > Subject: Re: [Sip] outbound: summary of issues > > > > John, > > > > Yes, this is what one thread of the discussion was about, > and you seem > > > to agree with #2 below > > > > Proxies inserting Supported: I think that would indeed be > > inappropriate as you indicate. > > What about feature tags a la callerprefs (RFC3841) in Path and > > Record-Route headers? > > > > Path: ;extensions="outbound" > > > > This would imply that proxies cannot indicate extensions without > > Record-Routing, but since the information is only relevant when the > > proxy stays in the path for next requests, this somehow feels > > appropriate to me > > > > Regards, > > > > jeroen > > > > ----- Original Message ----- > > From: "Elwell, John" > > To: "Jeroen van Bemmel" ; > > Sent: Wednesday, March 29, 2006 10:05 PM > > Subject: RE: [Sip] outbound: summary of issues > > > > > > > Jeroen, > > > > > > Thanks for your explanation. However, could we not limit > > use of Supported > > > outbound to the edge proxy. Since an edge proxy would not > > connect to the > > > registrar using outbound (I assume connect-reuse would be > > used instead), > > > then there is no reason for the registrar to place > > Supported outbound in > > > the > > > REGISTER response. This could be left for the edge proxy to > > insert. If it > > > is > > > felt inappropriate for a proxy to insert a Supported header > > tag, then > > > perhaps there is something else it can insert. This would > > seem much more > > > reliable than depending on configuration. > > > > > > John > > > > > >> -----Original Message----- > > >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > >> Sent: 29 March 2006 20:36 > > >> To: Elwell, John; sip@ietf.org > > >> Subject: Re: [Sip] outbound: summary of issues > > >> > > >> John, > > >> > > >> see inline > > >> > > >> > > >> ----- Original Message ----- > > >> From: "Elwell, John" > > >> To: "Jeroen van Bemmel" ; > > >> Sent: Wednesday, March 29, 2006 9:23 PM > > >> Subject: RE: [Sip] outbound: summary of issues > > >> > > >> > > >> > > > >> > > > >> >> -----Original Message----- > > >> >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > >> >> Sent: 29 March 2006 19:49 > > >> >> To: sip@ietf.org > > >> >> Subject: [Sip] outbound: summary of issues > > >> >> > > >> >> An attempt to summarize issues identified so far, in > the form of > > > >> >> closed questions: > > >> >> > > >> >> 1. Configuration of outbound proxies - desire to avoid manual > > >> >> configuration at the UAC. Do we agree that we want this? > > >> >> 1a If yes, in the outbound draft or as a separate draft? > > >> >> 2. Detection of outbound/keepalive support - desire > for dynamic > > >> >> discovery of support instead of (or perhaps in addition to) > > >> >> static configuration (the current keepalive=stun flag). Do we > > >> >> agree that we want this? (several options have been discussed) > > >> > [JRE] I can't recall what was wrong with just an option > > tag in the > > >> > Supported > > >> > header of the REGISTER response. > > >> > > >> That would indicate that the registrar supports > outbound, but says > > >> nothing about the edge proxy. The risk is that the UAC starts > > >> poking it with STUN requests while it is not supported. > > >> > > >> An outbound proxy URI with keepalive=stun would indicate proxy > > >> support, but that would only be an informed guess - there is the > > >> possibility for misconfiguration. To avoid this, it > would be good > > >> if the > > proxy would > > >> actively indicate that it supports outbound (in particular STUN). > > >> > > >> Jeroen > > >> > > >> > > > >> > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 04:38:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtaK-0006Gp-CK; Thu, 30 Mar 2006 04:36:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtaI-0006Gk-M9 for sip@ietf.org; Thu, 30 Mar 2006 04:36:54 -0500 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 1FOtaH-0001w3-BB for sip@ietf.org; Thu, 30 Mar 2006 04:36:54 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A6AF01D4; Thu, 30 Mar 2006 04:36:47 -0500 From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" , Subject: RE: [Sip] How to indicate during proxydiscoverythataproxysupports"outbound" Date: Thu, 30 Mar 2006 04:36:53 -0500 Message-ID: <034701c653dd$7c2a42a0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZTa2SJd+xgLBXRTSq4aZpl9Fg5pAAbryoQ In-Reply-To: <016c01c6536b$6687f4f0$31713b51@BEMBUSTER> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Jeroen, see inline... > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Wednesday, March 29, 2006 3:00 PM > > This was the gist of the idea I posted too. However, consider the > following > scenario: > > UAC - P1 - P2 - registrar > > UAC, P1, and the registrar all support outbound, P2 does not and also does > not add a Path header. In this case, P1 should initiate a flow directly to > the registrar, and keep it alive. However, keepalive support cannot be > detected from the top Via header in the response, since that was added by > P2! Huh? I'm confused. Why would P1 initiate a flow directly to P2? The keepalive is a socket ping, for UAC to P1 only. You mean for proxy-proxy keepalive? I don't think that's in scope for sip-outbound. I was just mentioning that the Via check idea/concept could potentially be re-used for a proxy-proxy, but I wasn't suggesting doing proxy-proxy for sip-outbound. > Another issue with proxy-proxy keepalive is: how would the UAC be notified > of flow failure? Although this topic is out of scope of sip-outbound - my answer would be "it wouldn't". It's not an end-end keepalive mechanism, and it's a generic proxy-to-proxy keepalive. The socket may be between any proxies, and could represent the link between 2 service providers connecting together millions of UAs. But that's why it's been pushed out of sip-outbound I think - so we can discuss the goals and issues later and get this one done and stun. :) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 04:56:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtre-0003dK-5R; Thu, 30 Mar 2006 04:54:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtrb-0003dF-La for sip@ietf.org; Thu, 30 Mar 2006 04:54:47 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOtra-0002NH-5X for sip@ietf.org; Thu, 30 Mar 2006 04:54:47 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2U9rgk3001092; Thu, 30 Mar 2006 12:53:43 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 12:54:43 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 12:54:42 +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] I-D ACTION:draft-ietf-sip-outbound-03.txt Date: Thu, 30 Mar 2006 12:54:42 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0222FDA9@esebe103.NOE.Nokia.com> In-Reply-To: <17451.32493.130932.496483@harjus.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZTxr/qnzfJe1ftQ0+0lmVQ0mvj5QAF4Tog From: To: , X-OriginalArrivalTime: 30 Mar 2006 09:54:42.0062 (UTC) FILETIME=[F76DD2E0:01C653DF] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sip@ietf.org, aki.niemi@nokia.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 ! I still wonder if it would be sufficient for the UA to automatically discover the proxies of certain domain, using NAPTR and SRV queries just like before (as described in RFC 3263), IF there is a way for the UA to detect the proxy and registrar support for Outbound within the REGISTER - 200 OK exchange ? If there is no Outbound support for the proxy the UA could potentially unregister and try sending REGISTER via another proxy, even if this kind of blind trying is not very efficient. There are some proposals for the SIP based detection being discussed, using mechanisms in either Via or Path headers. If one of those will be accepted and written into Outbound I-D, do we still need another mechanism to be specified ? I have recently ralized that the mechanism I have been proposing (new types of NAPTR records) suffers from a generic problem (which I identified but did not take so seriously) as described in SigComp related RFC 3486 as follows: A SIP [1] client sending a request to a SIP server typically performs a DNS lookup for the domain name of the server. When NAPTR [4] or SRV [5] records are available for the server, the client can specify the type of service it wants. The service in this context is the transport protocol to be used by SIP (e.g., UDP, TCP or SCTP). A SIP server that supports, for instance, three different transport protocols, will have three different DNS entries. Since it is foreseen that the number of transport protocols supported by a particular application layer protocol is not going to grow dramatically, having a DNS entry per transport seems like a scalable enough solution. However, sometimes it is necessary to include new layers between the transport protocol and the application layer protocol. Examples of these layers are transport layer security and compression. If DNS was used to discover the availability of these layers for a particular server, the number of DNS entries needed for that server would grow dramatically. A server that, for example, supported TCP and SCTP as transports, TLS for transport security and SigComp for signaling compression, would need the 8 DNS entries listed below: 1. TCP, no security, no compression 2. TCP, no security, SigComp 3. TCP, TLS, no compression 4. TCP, TLS, SigComp 5. SCTP, no security, no compression 6. SCTP, no security, SigComp 7. SCTP, TLS, no compression 8. SCTP, TLS, SigComp It is clear that this way of using DNS is not scalable. Therefore, an application layer mechanism to express support of signalling compression is needed. Defining new NAPTR service types for Outbound would have exactly similar effect. Regards, Erkki >-----Original Message----- >From: ext Juha Heinanen [mailto:jh@tutpro.com]=20 >Sent: 30.March.2006 09:47 >To: Cullen Jennings >Cc: sip@ietf.org; Niemi Aki (Nokia-NRC/Helsinki); Dean Willis >Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt > >Cullen Jennings writes: > > > As we agreed in the meeting, I would rather have these is separate > > documents since we can move forward with the what you do=20 >with it now and > > solve the many possible way beyond configuration how you=20 >might find it > > later.=20 > >it is fine to have a separate document describing how SIP UA finds >outbound-proxy-set, but that separate document MUST be=20 >referenced in the >outbound I-D in the same way as rfc3263 is referenced by=20 >rfc3261. there >is no point to publish a document where the only standards based way to >configure outbound-proxy-set is manually, because no regular user is >able to do it correctly. > >-- 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 Thu Mar 30 05:11:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOu5w-0001DU-IA; Thu, 30 Mar 2006 05:09:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOu5v-00019b-Iy for sip@ietf.org; Thu, 30 Mar 2006 05:09:35 -0500 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 1FOu5v-0002xn-4B for sip@ietf.org; Thu, 30 Mar 2006 05:09:35 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id AE58013C; Thu, 30 Mar 2006 05:09:28 -0500 From: "Hadriel Kaplan" To: "'Elwell, John'" , "'Christer Holmberg \(JO/LMF\)'" , "'Jeroen van Bemmel'" , Subject: RE: [Sip] outbound: summary of issues Date: Thu, 30 Mar 2006 05:09:36 -0500 Message-ID: <034801c653e2$0d2ac960$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZT2t4ME6PtDoz+QkqinNRlgne+CQAAqRhw In-Reply-To: <50B1CBA96870A34799A506B2313F26670889713A@ntht201e.siemenscomms.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba 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 Have you checked Brett Tate's idea of via-params? He emailed it to the list on Tuesday. It's elegant, I think. It's the following, snipped --------------------------- UAC adds Via parameter "outbound". And when the proxy/UAS observes it and supports receiving stun on this port/connection, it adds a parameter like "outbound=supported" or "outbound=required". ---------------------------- We may want to think about splitting it into two via-params: outb=yes, and ka=stun (or some such). First means you support outbound, second means you support stun keepalive. They could be mutually inclusive. If you can do outbound, you set the former. If you can do stun in this socket, you set latter. If you can do both you set both. And thus they're usable in future drafts independently. (For example if someone does a proxy-proxy draft and if it decided to use the same ka mechanism) -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Thursday, March 30, 2006 4:17 AM > To: Christer Holmberg (JO/LMF); Jeroen van Bemmel; sip@ietf.org > Subject: RE: [Sip] outbound: summary of issues > > Christian, > > Yes, you are right, Supported will not work, because an edge proxy that > doesn't support it cannot be expected to remove it! It seems that a new > header might be best. > > John > > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 30 March 2006 09:38 > > To: Elwell, John; Jeroen van Bemmel; sip@ietf.org > > Subject: RE: [Sip] outbound: summary of issues > > > > > > Hi, > > > > Will there be some other kind of information, related to > > outbound, that > > we need to transport? Anything related to the NAT keep-alive (timer > > values etc)? > > > > Since we are defining a new extension, we could also define a new > > header, which could carry the information. > > > > OR, as I wrote in another mail, do we want a more generic > > mechanism how > > nodes can indicate support for extensions and capabilities (other than > > outbound)? > > > > Because, in future there may be an extension which requires similar > > knowledge as now... > > > > Of course, one option is to modify the Supported header. But, then > > again, would it really work? Assume the registrar indicates that it > > supports outbound, but the proxy(s) between the UA and the > > registrar do > > not. The proxy(x), however, still insert a Path header, which > > means they > > will be in the path. But, how does the UA know which of the proxies > > (including the registrar) really supports outbound? > > > > Regards, > > > > Christer > > > > > > > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 30. maaliskuuta 2006 9:49 > > To: Jeroen van Bemmel; sip@ietf.org > > Subject: RE: [Sip] outbound: summary of issues > > > > Jeroen, > > > > I think it is important that the mechanism used by the UA to determine > > support for outbound be independent of whether there is a > > proxy present > > between the UA and the Registrar. The UA should not have to care about > > this. > > As I understand it, the Path header would be used only if there is an > > edge proxy present, so if the Path header were used to > > indicate support > > for outbound, then some other mechanism would be needed for when there > > is no proxy. > > > > Personally I prefer to use Supported, even if by manipulating the > > outbound tag at the proxy it violates normal use of Supported. > > > > John > > > > > -----Original Message----- > > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > Sent: 29 March 2006 22:13 > > > To: Elwell, John; sip@ietf.org > > > Subject: Re: [Sip] outbound: summary of issues > > > > > > John, > > > > > > Yes, this is what one thread of the discussion was about, > > and you seem > > > > > to agree with #2 below > > > > > > Proxies inserting Supported: I think that would indeed be > > > inappropriate as you indicate. > > > What about feature tags a la callerprefs (RFC3841) in Path and > > > Record-Route headers? > > > > > > Path: ;extensions="outbound" > > > > > > This would imply that proxies cannot indicate extensions without > > > Record-Routing, but since the information is only relevant when the > > > proxy stays in the path for next requests, this somehow feels > > > appropriate to me > > > > > > Regards, > > > > > > jeroen > > > > > > ----- Original Message ----- > > > From: "Elwell, John" > > > To: "Jeroen van Bemmel" ; > > > Sent: Wednesday, March 29, 2006 10:05 PM > > > Subject: RE: [Sip] outbound: summary of issues > > > > > > > > > > Jeroen, > > > > > > > > Thanks for your explanation. However, could we not limit > > > use of Supported > > > > outbound to the edge proxy. Since an edge proxy would not > > > connect to the > > > > registrar using outbound (I assume connect-reuse would be > > > used instead), > > > > then there is no reason for the registrar to place > > > Supported outbound in > > > > the > > > > REGISTER response. This could be left for the edge proxy to > > > insert. If it > > > > is > > > > felt inappropriate for a proxy to insert a Supported header > > > tag, then > > > > perhaps there is something else it can insert. This would > > > seem much more > > > > reliable than depending on configuration. > > > > > > > > John > > > > > > > >> -----Original Message----- > > > >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > >> Sent: 29 March 2006 20:36 > > > >> To: Elwell, John; sip@ietf.org > > > >> Subject: Re: [Sip] outbound: summary of issues > > > >> > > > >> John, > > > >> > > > >> see inline > > > >> > > > >> > > > >> ----- Original Message ----- > > > >> From: "Elwell, John" > > > >> To: "Jeroen van Bemmel" ; > > > >> Sent: Wednesday, March 29, 2006 9:23 PM > > > >> Subject: RE: [Sip] outbound: summary of issues > > > >> > > > >> > > > >> > > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > >> >> Sent: 29 March 2006 19:49 > > > >> >> To: sip@ietf.org > > > >> >> Subject: [Sip] outbound: summary of issues > > > >> >> > > > >> >> An attempt to summarize issues identified so far, in > > the form of > > > > > >> >> closed questions: > > > >> >> > > > >> >> 1. Configuration of outbound proxies - desire to avoid manual > > > >> >> configuration at the UAC. Do we agree that we want this? > > > >> >> 1a If yes, in the outbound draft or as a separate draft? > > > >> >> 2. Detection of outbound/keepalive support - desire > > for dynamic > > > >> >> discovery of support instead of (or perhaps in addition to) > > > >> >> static configuration (the current keepalive=stun flag). Do we > > > >> >> agree that we want this? (several options have been discussed) > > > >> > [JRE] I can't recall what was wrong with just an option > > > tag in the > > > >> > Supported > > > >> > header of the REGISTER response. > > > >> > > > >> That would indicate that the registrar supports > > outbound, but says > > > >> nothing about the edge proxy. The risk is that the UAC starts > > > >> poking it with STUN requests while it is not supported. > > > >> > > > >> An outbound proxy URI with keepalive=stun would indicate proxy > > > >> support, but that would only be an informed guess - there is the > > > >> possibility for misconfiguration. To avoid this, it > > would be good > > > >> if the > > > proxy would > > > >> actively indicate that it supports outbound (in particular STUN). > > > >> > > > >> Jeroen > > > >> > > > >> > > > > >> > 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 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 05:24:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuIH-0005XO-85; Thu, 30 Mar 2006 05:22:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuIF-0005We-T1 for sip@ietf.org; Thu, 30 Mar 2006 05:22:19 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOuIC-0003e3-QY for sip@ietf.org; Thu, 30 Mar 2006 05:22:19 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2F8464D9; Thu, 30 Mar 2006 12:22:16 +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, 30 Mar 2006 12:22:15 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 12:22: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound: summary of issues Date: Thu, 30 Mar 2006 12:22:15 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C1F@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound: summary of issues Thread-Index: AcZT2t4ME6PtDoz+QkqinNRlgne+CQAAqRhwAAFmWbA= From: "Christer Holmberg \(JO/LMF\)" To: "Hadriel Kaplan" , "Elwell, John" , "Jeroen van Bemmel" , X-OriginalArrivalTime: 30 Mar 2006 10:22:15.0633 (UTC) FILETIME=[D108BC10:01C653E3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 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, Via is of course one possibility, but that changes the whole concept of Via. However, if we want to do that, I believe we should look at it from a more generic perspecitve, allowing nodes to also indicate other types of capabilities. Another option would be that the edge proxy - ASSUMING it knows it's the edge proxy - inserts a dedicated header value. For example, the registrar and/or other proxies may insert "outbound", but the edge proxy inserts "outbound-edge". Then the UA will know whether the edge proxy really supports outbound. The UA would not know which of the other proxies support outbound, but that is maybe not important. OR, the edge proxy should be the only node inserting support for outbound. Why should other proxies have to do it? But, again, this assumes the proxy knows if it is acting as edge or not. A third option is of course to send OPTIONS to the edge proxy, but that of course causes more traffic. Regards, Christer =20 -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: 30. maaliskuuta 2006 13:10 To: 'Elwell, John'; Christer Holmberg (JO/LMF); 'Jeroen van Bemmel'; sip@ietf.org Subject: RE: [Sip] outbound: summary of issues Have you checked Brett Tate's idea of via-params? He emailed it to the list on Tuesday. It's elegant, I think. It's the following, snipped --------------------------- UAC adds Via parameter "outbound". And when the proxy/UAS observes it and supports receiving stun on this port/connection, it adds a parameter like "outbound=3Dsupported" or "outbound=3Drequired". ---------------------------- We may want to think about splitting it into two via-params: outb=3Dyes, and ka=3Dstun (or some such). First means you support outbound, second means you support stun keepalive. They could be mutually inclusive. If you can do outbound, you set the former. If you can do stun in this socket, you set latter. If you can do both you set both. And thus they're usable in future drafts independently. (For example if someone does a proxy-proxy draft and if it decided to use the same ka mechanism) -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Thursday, March 30, 2006 4:17 AM > To: Christer Holmberg (JO/LMF); Jeroen van Bemmel; sip@ietf.org > Subject: RE: [Sip] outbound: summary of issues >=20 > Christian, >=20 > Yes, you are right, Supported will not work, because an edge proxy=20 > that doesn't support it cannot be expected to remove it! It seems that > a new header might be best. >=20 > John >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 30 March 2006 09:38 > > To: Elwell, John; Jeroen van Bemmel; sip@ietf.org > > Subject: RE: [Sip] outbound: summary of issues > > > > > > Hi, > > > > Will there be some other kind of information, related to outbound,=20 > > that we need to transport? Anything related to the NAT keep-alive=20 > > (timer values etc)? > > > > Since we are defining a new extension, we could also define a new=20 > > header, which could carry the information. > > > > OR, as I wrote in another mail, do we want a more generic mechanism=20 > > how nodes can indicate support for extensions and capabilities=20 > > (other than outbound)? > > > > Because, in future there may be an extension which requires similar=20 > > knowledge as now... > > > > Of course, one option is to modify the Supported header. But, then=20 > > again, would it really work? Assume the registrar indicates that it=20 > > supports outbound, but the proxy(s) between the UA and the registrar > > do not. The proxy(x), however, still insert a Path header, which=20 > > means they will be in the path. But, how does the UA know which of=20 > > the proxies (including the registrar) really supports outbound? > > > > Regards, > > > > Christer > > > > > > > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 30. maaliskuuta 2006 9:49 > > To: Jeroen van Bemmel; sip@ietf.org > > Subject: RE: [Sip] outbound: summary of issues > > > > Jeroen, > > > > I think it is important that the mechanism used by the UA to=20 > > determine support for outbound be independent of whether there is a=20 > > proxy present between the UA and the Registrar. The UA should not=20 > > have to care about this. > > As I understand it, the Path header would be used only if there is=20 > > an edge proxy present, so if the Path header were used to indicate=20 > > support for outbound, then some other mechanism would be needed for=20 > > when there is no proxy. > > > > Personally I prefer to use Supported, even if by manipulating the=20 > > outbound tag at the proxy it violates normal use of Supported. > > > > John > > > > > -----Original Message----- > > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > Sent: 29 March 2006 22:13 > > > To: Elwell, John; sip@ietf.org > > > Subject: Re: [Sip] outbound: summary of issues > > > > > > John, > > > > > > Yes, this is what one thread of the discussion was about, > > and you seem > > > > > to agree with #2 below > > > > > > Proxies inserting Supported: I think that would indeed be=20 > > > inappropriate as you indicate. > > > What about feature tags a la callerprefs (RFC3841) in Path and=20 > > > Record-Route headers? > > > > > > Path: ;extensions=3D"outbound" > > > > > > This would imply that proxies cannot indicate extensions without=20 > > > Record-Routing, but since the information is only relevant when=20 > > > the proxy stays in the path for next requests, this somehow feels=20 > > > appropriate to me > > > > > > Regards, > > > > > > jeroen > > > > > > ----- Original Message ----- > > > From: "Elwell, John" > > > To: "Jeroen van Bemmel" ; > > > Sent: Wednesday, March 29, 2006 10:05 PM > > > Subject: RE: [Sip] outbound: summary of issues > > > > > > > > > > Jeroen, > > > > > > > > Thanks for your explanation. However, could we not limit > > > use of Supported > > > > outbound to the edge proxy. Since an edge proxy would not > > > connect to the > > > > registrar using outbound (I assume connect-reuse would be > > > used instead), > > > > then there is no reason for the registrar to place > > > Supported outbound in > > > > the > > > > REGISTER response. This could be left for the edge proxy to > > > insert. If it > > > > is > > > > felt inappropriate for a proxy to insert a Supported header > > > tag, then > > > > perhaps there is something else it can insert. This would > > > seem much more > > > > reliable than depending on configuration. > > > > > > > > John > > > > > > > >> -----Original Message----- > > > >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > >> Sent: 29 March 2006 20:36 > > > >> To: Elwell, John; sip@ietf.org > > > >> Subject: Re: [Sip] outbound: summary of issues > > > >> > > > >> John, > > > >> > > > >> see inline > > > >> > > > >> > > > >> ----- Original Message ----- > > > >> From: "Elwell, John" > > > >> To: "Jeroen van Bemmel" ; > > > >> Sent: Wednesday, March 29, 2006 9:23 PM > > > >> Subject: RE: [Sip] outbound: summary of issues > > > >> > > > >> > > > >> > > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > >> >> Sent: 29 March 2006 19:49 > > > >> >> To: sip@ietf.org > > > >> >> Subject: [Sip] outbound: summary of issues > > > >> >> > > > >> >> An attempt to summarize issues identified so far, in > > the form of > > > > > >> >> closed questions: > > > >> >> > > > >> >> 1. Configuration of outbound proxies - desire to avoid=20 > > > >> >> manual configuration at the UAC. Do we agree that we want this? > > > >> >> 1a If yes, in the outbound draft or as a separate draft? > > > >> >> 2. Detection of outbound/keepalive support - desire > > for dynamic > > > >> >> discovery of support instead of (or perhaps in addition to)=20 > > > >> >> static configuration (the current keepalive=3Dstun flag). Do = > > > >> >> we agree that we want this? (several options have been=20 > > > >> >> discussed) > > > >> > [JRE] I can't recall what was wrong with just an option > > > tag in the > > > >> > Supported > > > >> > header of the REGISTER response. > > > >> > > > >> That would indicate that the registrar supports > > outbound, but says > > > >> nothing about the edge proxy. The risk is that the UAC starts=20 > > > >> poking it with STUN requests while it is not supported. > > > >> > > > >> An outbound proxy URI with keepalive=3Dstun would indicate = proxy=20 > > > >> support, but that would only be an informed guess - there is=20 > > > >> the possibility for misconfiguration. To avoid this, it > > would be good > > > >> if the > > > proxy would > > > >> actively indicate that it supports outbound (in particular STUN). > > > >> > > > >> Jeroen > > > >> > > > >> > > > > >> > John > > > >> > > > > > > > _______________________________________________ > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 05:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuRC-0002mk-Fv; Thu, 30 Mar 2006 05:31:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuRA-0002me-Bv for sip@ietf.org; Thu, 30 Mar 2006 05:31:32 -0500 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 1FOuRA-0004D2-17 for sip@ietf.org; Thu, 30 Mar 2006 05:31:32 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A37501A8; Thu, 30 Mar 2006 05:31:17 -0500 From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" , "'Cullen Jennings'" , "'Dean Willis'" , Subject: RE: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" Date: Thu, 30 Mar 2006 05:31:25 -0500 Message-ID: <034901c653e5$196196c0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZTwMPGDUWQGwRiSVGvT3vL31nJhAAE5f5Q In-Reply-To: <002601c653c0$4880e1b0$31713b51@BEMBUSTER> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: '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 Hi Jeroen, The whole point is actually to make it a MUST that the UA perform a "safe" check, where "safe" means a sip-compliant check, before it does anything bad. It cannot be a choice of a sip-outbound compliant UA to just do bad if it wishes. It's not actually the outbound sip changes that are the big problem, it's really the binary/stun messages. I'm not overly worried about anyone sending new sip signaling - of course you can send that. Every new draft/RFC does that, and the beauty of SIP is to have that backwards-compatible flexibility. If the new sip-signaling needs to be understood by boxes that didn't have to understand it before because they may create issues for the legacy sip "network", well that's a problem from a SIP WG perspective I would think. And that is also a problem right now, perhaps, if a sip-outbound UA assumes the edge proxy is a sip-outbound proxy, when it is not. Right now the draft has no way to let the UA know the edge-proxy supports outbound. It has a way for it to know the registrar does, although even then it doesn't say that knowledge must be used for anything. The results of that may lead to constant forking, which is probably not a good thing. But the REAL problem is the UA can send a binary message. I understand why we want to do that, and although I hated the idea at first, I am willing to accept the decision and it's growing on me. BUT, it's still a major issue if UAs can send it when they like. They MUST safely check to make sure it's ok. It's not a major issue for my company - our products will handle it fine. But I can't speak for others. And not everyone who makes a sip-compliant proxy/registrar/UAS follows this mailing list. And people have all kinds of old software out there, which may be hard to upgrade. One only needs to look at the initial Protos test results to get an idea of the potential. Do we really want CERT Advisories issued, and the root cause being the IETF SIP Working Group??? Ironically, that would be good for firewall and SBC vendors - but not good for SIP. We have to do as much as possible to prevent it. -Hadriel > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Thursday, March 30, 2006 1:08 AM > To: Cullen Jennings; Dean Willis; sip@ietf.org > Cc: Juha Heinanen > Subject: Re: [Sip] How to indicate during proxy discovery that a > proxysupports"outbound" > > > On 3/25/06 1:53 PM, "Jeroen van Bemmel" wrote: > > > >> Could you explain why it is needed that the UA knows whether the proxy > >> supports outbound before sending its REGISTER request? > > > > So that we don't send things to the proxy that it does not understand. > > Some > > people did not care about this - some felt strongly about it. Some > pointed > > out that the proxy might black list a client that seemed to be > "attacking > > it" with bogus packets. > > The people that feel strongly about this could add 'Require: outbound' to > their request. Implementations that would blacklist such clients would be > considered broken. > > An alternative would perhaps be to depend on an authentication challenge: > first send a normal REGISTER, challenge, respond to the challenge and if > Supported: outbound is there modify the request as needed. Not common > practice though... > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 06:13:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOv3q-0000DH-Ox; Thu, 30 Mar 2006 06:11:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOv3p-0000DC-R0 for sip@ietf.org; Thu, 30 Mar 2006 06:11:29 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOv3o-0005wD-Fq for sip@ietf.org; Thu, 30 Mar 2006 06:11:29 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FOv3m-0002PB-TL; Thu, 30 Mar 2006 14:11:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17451.48350.852998.215802@harjus.tutpro.com> Date: Thu, 30 Mar 2006 14:11:26 +0300 To: Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0222FDA9@esebe103.NOE.Nokia.com> References: <17451.32493.130932.496483@harjus.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F0222FDA9@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: fluffy@cisco.com, sip@ietf.org, aki.niemi@nokia.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 Erkki.Koivusalo@nokia.com writes: > I still wonder if it would be sufficient for the UA to automatically > discover the proxies of certain domain, using NAPTR and SRV > queries just like before (as described in RFC 3263), IF there > is a way for the UA to detect the proxy and registrar support > for Outbound within the REGISTER - 200 OK exchange ? erkki, as klaus me and others have said, the new "outbound" NAPTR records bring great value to SIP, because they allow local SIP UAs to detect a different set of proxies than what foreign SIP UAs and proxies detect using existing NAPTR records. -- 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 Thu Mar 30 06:17:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOv7p-0002wC-5u; Thu, 30 Mar 2006 06:15:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOv7n-0002w7-6d for sip@ietf.org; Thu, 30 Mar 2006 06:15:35 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOv7m-00065Y-Sn for sip@ietf.org; Thu, 30 Mar 2006 06:15:35 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1FOv7m-0002PW-6I; Thu, 30 Mar 2006 14:15:34 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17451.48598.91056.323787@harjus.tutpro.com> Date: Thu, 30 Mar 2006 14:15:34 +0300 To: Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0222FDA9@esebe103.NOE.Nokia.com> References: <17451.32493.130932.496483@harjus.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F0222FDA9@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: fluffy@cisco.com, sip@ietf.org, aki.niemi@nokia.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 Erkki.Koivusalo@nokia.com writes: > Defining new NAPTR service types for Outbound would have exactly > similar effect. it would about double the current number of records, but would also bring the benefits i mentioned in my previous message. it is hard to envision how you could otherwise separate proxies for use by local SIP UAs from proxies for use by other UAs and 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 Thu Mar 30 06:56:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOvjw-0001GN-Do; Thu, 30 Mar 2006 06:55:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOvju-0001Cv-E7 for sip@ietf.org; Thu, 30 Mar 2006 06:54:58 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOvjt-0007Zq-Vx for sip@ietf.org; Thu, 30 Mar 2006 06:54:58 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2UBrduN005710; Thu, 30 Mar 2006 14:53:39 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 14:54:56 +0300 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 30 Mar 2006 14:54:56 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2UBstQ04079; Thu, 30 Mar 2006 14:54:55 +0300 (EET DST) Received: from (none) (hed038-155.research.nokia.com [172.21.38.155]) by kusti.research.nokia.com (Postfix) with ESMTP id 9715C93B75; Thu, 30 Mar 2006 14:54:55 +0300 (EEST) Received: from hed035-181.research.nokia.com (localhost [127.0.0.1]) by (none) (8.13.1/8.13.1) with ESMTP id k2UBstgr007576; Thu, 30 Mar 2006 14:54:55 +0300 Received: (from ppessi@localhost) by hed035-181.research.nokia.com (8.13.1/8.13.1/Submit) id k2UBst39007575; Thu, 30 Mar 2006 14:54:55 +0300 X-Authentication-Warning: hed035-181.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Jeroen van Bemmel , Subject: Re: [Sip] outbound: summary of issues X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: iPekka Pessi In-Reply-To: <007201c65361$7decec90$31713b51@BEMBUSTER> (Jeroen van Bemmel's message of "Wed, 29 Mar 2006 20:49:21 +0200") References: <007201c65361$7decec90$31713b51@BEMBUSTER> Date: Thu, 30 Mar 2006 14:54:54 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 30 Mar 2006 11:54:56.0690 (UTC) FILETIME=[C3AEB120:01C653F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Jeroen van Bemmel writes: >An attempt to summarize issues identified so far, in the form of closed questions: >1. Configuration of outbound proxies - desire to avoid manual configuration >at the UAC. Do we agree that we want this? >1a If yes, in the outbound draft or as a separate draft? >2. Detection of outbound/keepalive support - desire for dynamic discovery of >support instead of (or perhaps in addition to) static configuration (the >current keepalive=stun flag). Do we agree that we want this? (several >options have been discussed) We do. I'd go for outbound feature tag with some more work for edge proxies and registrar. 1) When an edge proxy receives a REGISTER request with a sip.instance (and a reg-id?) param in Contact header field, it would add itself to the Path header. In addition to the flow-id, it would add keepalive=stun parameter in the Path URI. 2) When registrar receives a REGISTER request with a sip.instance and reg-id param, it would check for presence of Path headers. If the last Path header field does not contain keepalive=stun URI parameter, it MUST NOT include outbound feature tag in 2XX response and it MUST ignore the reg-id parameter. So, when registrar includes "outbound" in Supported header, it knows either 1) edge proxy supports keepalive=stun or 2) it itself supports keepalive=stun. I hope UAC can trust registrar here. As an alternative, we could mandate that the registrar/home proxy adds its own URI with keepalive=stun to the Path header. Again, UAC would have to check only one place, the keepalive=stun header field in last Path header. But that would mean that UAC could not ignore the Path header as it does now. In all cases, there is the issue of intermediate proxies not inserting Path headers. Simplest thing is to count Via headers: if there is more than one Via header, proxy cannot support outbound/keepalive=stun unless it has some intimate knowledge of other proxies listed in the Via headers. >3. Deployment scenarios - do we want to support: > 3a NAT between the edge proxy and the registrar (or more general: NAT >beyond the first hop) I would vote for connection reuse in this case. Edge proxy should have a certificate. > 3b UAC - edge proxy - registrar where the edge proxy adds Path but does not >support outbound/keep-alive My vote: no outbound, use gruu and hope that Path header is enough. > 3c UAC - edge proxy - registrar where the edge proxy does not support/add >Path (i.e. it drops out) You mean that UAC connects directly to registrar? Not in outbound, I'd say.. --Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 07:13:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOvzo-0004fG-33; Thu, 30 Mar 2006 07:11:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOvzm-0004fB-8N for sip@ietf.org; Thu, 30 Mar 2006 07:11:22 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOvzl-0008Nz-Rt for sip@ietf.org; Thu, 30 Mar 2006 07:11:22 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2UCBF79005345; Thu, 30 Mar 2006 06:11:15 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Mar 2006 13:11:14 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0127496D8@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] draft-ietf-sip-outbound Date: Thu, 30 Mar 2006 13:11:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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 The meeting report will report the agreements (and possibly = discussions) made at the meeting. It is not the responsibility of the meeting report to document the = extensive exchange of emails before the meeting, which contains 80% of = the base input to the decisions that were made. regards Keith -----Original Message----- From: Christer Holmberg (JO/LMF) = [mailto:christer.holmberg@ericsson.com] Sent: 29 March 2006 20:37 To: Francois Audet; Elwell, John; Chris Boulton; Hisham Khartabil; = Samir Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Hi, As I said, it doesn't have to be in the document - it can be in the = meeting report. All I'm asking for, since I wasn't able to attend the meeting, are the = arguments that were presented, which were then used for people to vote = for a specific solution. Is that too much to ask for???=20 I don't think what I'm asking for is going to delay the work on the = draft. A choise has been made, and we should stick to it.=20 Regards, Christer From: Francois Audet [mailto:audet@nortel.com]=20 Sent: 29. maaliskuuta 2006 19:23 To: Christer Holmberg (JO/LMF); Elwell, John; Chris Boulton; Hisham = Khartabil; Samir Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound I don't understand why we need to do this. We've never done this before = in IETF that I can remember, and it seems to me to bean undue burden on the editors. Being a bunch = of engineers, we risk arguing endlessly about the justification itself (like we did on the mailing = list for 12 months). Instead of "making it go away", this explanation will just bring us = back 12 months. If the vote had been really close, maybe, but it wasn't: it was me and = four others against 185. I'd rather we spend time issuing the draft, and finishing up the vast = number of drafts waiting in the queue. ---- Fran=E7ois AUDET, Nortel Networks mailto:audet@nortel.com -----Original Message----- From: Christer Holmberg (JO/LMF) = [mailto:christer.holmberg@ericsson.com] Sent: Wed 29-Mar-06 4:10 AM To: Elwell, John; Chris Boulton; Hisham Khartabil; Srivastava, Samir = [SC100:8826:EXCH] Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Hi, If the meeting report will show why this solution was chosen, compared to others, and the arguments/pros/cons that were presented for the different solutions, before people were asked to raise their hand for one of the solutions, I will be happy. If the meeting report will only say "There was a concensus for STUN" it won't help very much, and I am pretty sure questions will come up again in the future ("I have just read this RFC, and I wonder why I can't use instead."). Also, since the network initiated keep-alives obviously were not discussed (please correct me if I'm wrong), I wonder if it would be possible to add some text in the draft indicating it is "out of the scope of the document", it is "for future work", or whatever, because = as far as I am aware the whole discussion/scope has been about UA = initiaded keep-alives. Regards, Christer -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: 29. maaliskuuta 2006 15:01 To: Chris Boulton; Hisham Khartabil; Samir Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Yes, the mailing list archives and meeting minutes will show the reasons. I don't see the need for yet another draft and endless discussion during its production. Don't we have enough work to do? = Let's just move on and get outbound finished. John > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 29 March 2006 12:47 > To: Hisham Khartabil; Samir Srivastava > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-outbound > > I'm with Hisham on this - this has been discussed at length and a > choice has been made. I certainly don't see the need to add another > draft - we have way too many to read as it is. I was also at the > meeting and feel that such decisions should just be accepted (the > consensus was > overwhelming) - otherwise we will find ourselves stuck on the same = old > IETF roundabout. > > Chris. > > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: 29 March 2006 08:42 > To: Samir Srivastava > Cc: sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-outbound > > I don't agree. This is being done without documenting it. Once > documented, it will never go away. We all know that. > > Hisham > > On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote: > > > > > This seems like a good reason for this (or another) draft > to discuss > > the > > alternative solutions for use until the STUN solution is > supported by > > both devices. Since the draft is basically silent, vendors > will just > > fallback to flooding the network with their favorite SIP request > > (REGISTERs, etcetera) for solving the problem without much > guidance or > > potential optimizations. > > > > > > SS>> I agree. > > > > I captured following from SIPIT-16 (Apr 05) report. I couldn't find > > SIPIT-17 report from archive. Can somebody update on outbound from > > that. > > > > "There were 10 teams with implementations doing various things to > > keep NAT bindings alive (sending CRLFs, empty media packets, etc). > > The remainder were not attempting to address the problem at this > > time." > > > > There are *Empty Media Packets* too !! > > > > > > Thx > > Samir > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > Information contained in this e-mail and any attachments are intended > for the use of the addressee only, and may contain confidential > information of Ubiquity Software Corporation. > All unauthorized use, disclosure or distribution is strictly > prohibited. If you are not the addressee, please notify the sender > immediately and destroy all copies of this email. > Unless otherwise expressly agreed in writing signed by an officer of > Ubiquity Software Corporation, nothing in this communication shall be > deemed to be legally binding. Thank you. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 07:19:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOw5L-0001Hr-MC; Thu, 30 Mar 2006 07:17:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOw5J-0001E4-JX for sip@ietf.org; Thu, 30 Mar 2006 07:17:05 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOw5I-0000Ic-Om for sip@ietf.org; Thu, 30 Mar 2006 07:17:05 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2F58E613; Thu, 30 Mar 2006 14:17:04 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 14:17:03 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 14:17: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] draft-ietf-sip-outbound Date: Thu, 30 Mar 2006 14:17:03 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C23@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZT8xJpK294R1pBR0COWgbf9sX/mAAAJQmQ From: "Christer Holmberg \(JO/LMF\)" To: "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 30 Mar 2006 12:17:03.0526 (UTC) FILETIME=[DA89CC60:01C653F3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 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 Keith, I am not asking anyone to document the email exchange. I am simply = asking to document what happened at the meeting. And, if the only thing that was said at the meeting was "You have seen = the e-mail discussion, now let's vote" then please say so... Regards, Christer=20 -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: 30. maaliskuuta 2006 15:11 To: Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound The meeting report will report the agreements (and possibly discussions) = made at the meeting. It is not the responsibility of the meeting report to document the = extensive exchange of emails before the meeting, which contains 80% of = the base input to the decisions that were made. regards Keith -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: 29 March 2006 20:37 To: Francois Audet; Elwell, John; Chris Boulton; Hisham Khartabil; Samir = Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Hi, As I said, it doesn't have to be in the document - it can be in the = meeting report. All I'm asking for, since I wasn't able to attend the meeting, are the = arguments that were presented, which were then used for people to vote = for a specific solution. Is that too much to ask for???=20 I don't think what I'm asking for is going to delay the work on the = draft. A choise has been made, and we should stick to it.=20 Regards, Christer From: Francois Audet [mailto:audet@nortel.com] Sent: 29. maaliskuuta 2006 19:23 To: Christer Holmberg (JO/LMF); Elwell, John; Chris Boulton; Hisham = Khartabil; Samir Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound I don't understand why we need to do this. We've never done this before = in IETF that I can remember, and it seems to me to bean undue burden on the editors. Being a bunch = of engineers, we risk arguing endlessly about the justification itself (like we did on the mailing = list for 12 months). Instead of "making it go away", this explanation will just bring us back = 12 months. If the vote had been really close, maybe, but it wasn't: it was me and = four others against 185. I'd rather we spend time issuing the draft, and finishing up the vast = number of drafts waiting in the queue. ---- Fran=E7ois AUDET, Nortel Networks mailto:audet@nortel.com -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: Wed 29-Mar-06 4:10 AM To: Elwell, John; Chris Boulton; Hisham Khartabil; Srivastava, Samir = [SC100:8826:EXCH] Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Hi, If the meeting report will show why this solution was chosen, compared to others, and the arguments/pros/cons that were presented for the different solutions, before people were asked to raise their hand for one of the solutions, I will be happy. If the meeting report will only say "There was a concensus for STUN" it won't help very much, and I am pretty sure questions will come up again in the future ("I have just read this RFC, and I wonder why I can't use instead."). Also, since the network initiated keep-alives obviously were not discussed (please correct me if I'm wrong), I wonder if it would be possible to add some text in the draft indicating it is "out of the scope of the document", it is "for future work", or whatever, because as far as I am aware the whole discussion/scope has been about UA initiaded keep-alives. Regards, Christer -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: 29. maaliskuuta 2006 15:01 To: Chris Boulton; Hisham Khartabil; Samir Srivastava Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-outbound Yes, the mailing list archives and meeting minutes will show the reasons. I don't see the need for yet another draft and endless discussion during its production. Don't we have enough work to do? Let's just move on and get outbound finished. John > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 29 March 2006 12:47 > To: Hisham Khartabil; Samir Srivastava > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-outbound > > I'm with Hisham on this - this has been discussed at length and a > choice has been made. I certainly don't see the need to add another > draft - we have way too many to read as it is. I was also at the > meeting and feel that such decisions should just be accepted (the > consensus was > overwhelming) - otherwise we will find ourselves stuck on the same old > IETF roundabout. > > Chris. > > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: 29 March 2006 08:42 > To: Samir Srivastava > Cc: sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-outbound > > I don't agree. This is being done without documenting it. Once > documented, it will never go away. We all know that. > > Hisham > > On Mar 28, 2006, at 10:38 PM, Samir Srivastava wrote: > > > > > This seems like a good reason for this (or another) draft > to discuss > > the > > alternative solutions for use until the STUN solution is > supported by > > both devices. Since the draft is basically silent, vendors > will just > > fallback to flooding the network with their favorite SIP request > > (REGISTERs, etcetera) for solving the problem without much > guidance or > > potential optimizations. > > > > > > SS>> I agree. > > > > I captured following from SIPIT-16 (Apr 05) report. I couldn't find > > SIPIT-17 report from archive. Can somebody update on outbound from > > that. > > > > "There were 10 teams with implementations doing various things to > > keep NAT bindings alive (sending CRLFs, empty media packets, etc). > > The remainder were not attempting to address the problem at this > > time." > > > > There are *Empty Media Packets* too !! > > > > > > Thx > > Samir > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > Information contained in this e-mail and any attachments are intended > for the use of the addressee only, and may contain confidential > information of Ubiquity Software Corporation. > All unauthorized use, disclosure or distribution is strictly > prohibited. If you are not the addressee, please notify the sender > immediately and destroy all copies of this email. > Unless otherwise expressly agreed in writing signed by an officer of > Ubiquity Software Corporation, nothing in this communication shall be > deemed to be legally binding. Thank you. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 09:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOxgj-0005z4-MX; Thu, 30 Mar 2006 08:59:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOxgi-0005yz-CR for sip@ietf.org; Thu, 30 Mar 2006 08:59:48 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOxgh-0004mp-Qn for sip@ietf.org; Thu, 30 Mar 2006 08:59:48 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2UDwkH1029842; Thu, 30 Mar 2006 16:58:46 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 16:59:47 +0300 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 30 Mar 2006 16:59:46 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2UDxjQ00863; Thu, 30 Mar 2006 16:59:45 +0300 (EET DST) Received: from (none) (hed038-155.research.nokia.com [172.21.38.155]) by kusti.research.nokia.com (Postfix) with ESMTP id 80B7993B75; Thu, 30 Mar 2006 16:59:45 +0300 (EEST) Received: from hed035-181.research.nokia.com (localhost [127.0.0.1]) by (none) (8.13.1/8.13.1) with ESMTP id k2UDxjlC022724; Thu, 30 Mar 2006 16:59:45 +0300 Received: (from ppessi@localhost) by hed035-181.research.nokia.com (8.13.1/8.13.1/Submit) id k2UDxbYQ022723; Thu, 30 Mar 2006 16:59:37 +0300 X-Authentication-Warning: hed035-181.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: "Drage, Keith (Keith)" Subject: Use of reg-id and instance-id (Re: [Sip] draft-ietf-sip-outbound) X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: iPekka Pessi In-Reply-To: <475FF955A05DD411980D00508B6D5FB012749189@en0033exch001u.uk.lucent.com> (Keith Drage's message of "Sat, 25 Mar 2006 00:51:01 -0000") References: <475FF955A05DD411980D00508B6D5FB012749189@en0033exch001u.uk.lucent.com> Date: Thu, 30 Mar 2006 16:59:36 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 30 Mar 2006 13:59:46.0236 (UTC) FILETIME=[33CCB7C0:01C65402] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 "Drage, Keith (Keith)" writes: >3) Working group: Are we ready to move to WGLC. Please indicate if you consider this document needs more work preceding WGLC. I think the text discussing instance-id/reg-id and relationship between outbound and gruu needs some dusting. 1. Is reg-id mandatory? The section 4.1 says that UAC MUST include reg-id in Contact (unless it is doing 3rd party registration, or so I interpret 4.1). I suppose the contact with instance-id but no reg-id is just a gruu-hopeful, not outbound. Perhaps outbound spec could mention that using instance-id without reg-id in UAC and edge proxies is explained elsewhere. In any case, the examples and overview only confuse when they explain the usage without reg-id. So, I'd propose replacing the text in section 3.2: User Agents which form only a single flow continue to register normally but include the instance-id as described in Section 4.1. The UA can also include a reg-id parameter is used to allow the registrar to detect and avoid using invalid contacts when a UA with User Agents which form only a single flow continue to register normally but include the instance-id and reg-id as described in Section 4.1. The reg-id parameter is used to allow the registrar to detect and avoid using invalid contacts when a UA 2. How bindings with instance-id are handled in registrar? The second paragraph in outbound-03 section 6.1 describes how a binding with instance-id shuld be processed. If there is instance-id the URI should be ignored when comparing and reg-id/instance-id pair should be used instead. My understanding is that the binding comparison in registrar is used to locate the bindings that the REGISTER request updates, like the first paragraph of page 66 in RFC 3261 describes. Is this the comparison to which the second paragraph in 6.1 refers? Or does the registrar still use the URI comparison when updating the bindings but delay the pruning of bingings until the target-set selection time? So, if UA has registered contact 1 with instance-id A, reg-id 1 and URI U1, then registers contact 2 with instance-id A, reg-id 1 but URI U2, the new contact replaces old one. Or does it just keep all the entries, but ignore contact 1 until contact 2 expires or it is unregistered (like text in 3.2 implies)? So, I propose that the intention is spelled out in 6.1, for instance like this: combination of instance-id and reg-id. When searcing existing bindings to update, registrar matches a Contact header field with an instance-id with a current binding containg same instance-id and reg-id, regardless of the URI stored with the binding (the Contact URI is not part of the "key" for the binding). The registrar still stores the Contact header field value URI with the binding. Also, I'd propose updating the text in overview section. Replace 3.2 (page 7): the Contact header field. If the instance-id and reg-id are the same as a previous registration for the same AOR, the proxy uses the most recently created registration first. This allows a UA that has rebooted to replace its previous registration for each flow with minimal impact on overall system load. with the Contact header field. If the instance-id and reg-id are the same as a previous registration for the same AOR, the proxy replaces old registration with new one. This allows a UA that has rebooted to update its previous registration for each flow with minimal impact on overall system load. and this that has the same instance-id as the selected UA. In general, if two registrations have the same reg-id and instance-id, the proxy will favor the most recently registered flow. This is so that if a UA reboots, the proxy will prefer to use the most recent flow that goes to this UA instead of trying one of the old flows which would presumably fail. with that has the same instance-id as the selected UA. The new registrations with same reg-id and instance-id will replace the old flows. This is so that if a UA reboots, the proxy will use only the most recent flow that goes to this UA instead of trying one of the old flows which would presumably fail. 3. Should registrar/edge proxy use outbound in absense of reg-id? (NO?) Gruu is relatively lightweight (adding the Path header to REGISTER) compared with outbound (keeping connection, consume sockets) so I feel that gruu should not require using outbound in edge proxy, especially if the edge proxy is reachable from outside and can establish TCP connections towards UA when needed. So, the requirement of caching the connection 5.1 could be relaxed so that the flow-id would be required only when there is both reg-id and instance-id in Contact of REGISTER request. 4. What happens when an edge proxy closes the connection? The last paragraph in 6.2 says that when the connecion is closed (FIN on TCP, destination unreachable ICMP on UDP), the binding must be removed. Does this happen only when there is reg-id, or even without reg-id? Does it happen with Path, or without Path? --Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 09:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyJJ-00046S-Gy; Thu, 30 Mar 2006 09:39:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyJI-00043G-Bn; Thu, 30 Mar 2006 09:39:40 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOyJH-0007lq-RA; Thu, 30 Mar 2006 09:39:40 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2UEdFJ1016173; Thu, 30 Mar 2006 17:39:16 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 17:39:38 +0300 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 30 Mar 2006 17:39:38 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2UEdYQ07682; Thu, 30 Mar 2006 17:39:34 +0300 (EET DST) Received: from (none) (hed038-155.research.nokia.com [172.21.38.155]) by kusti.research.nokia.com (Postfix) with ESMTP id 5FC9593B75; Thu, 30 Mar 2006 17:39:34 +0300 (EEST) Received: from hed035-181.research.nokia.com (localhost [127.0.0.1]) by (none) (8.13.1/8.13.1) with ESMTP id k2UEdYsK022803; Thu, 30 Mar 2006 17:39:34 +0300 Received: (from ppessi@localhost) by hed035-181.research.nokia.com (8.13.1/8.13.1/Submit) id k2UEdRpt022801; Thu, 30 Mar 2006 17:39:27 +0300 X-Authentication-Warning: hed035-181.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: "sip-bounces@ietf.org" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: iPekka Pessi In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F021C87AE@esebe103.NOE.Nokia.com> (sip-bounces@ietf.org's message of "Fri, 24 Mar 2006 15:14:58 +0200") References: <8B1D53AEF7B03449A6D3771B3B7F850F021C87AE@esebe103.NOE.Nokia.com> Date: Thu, 30 Mar 2006 17:39:26 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 30 Mar 2006 14:39:38.0256 (UTC) FILETIME=[C58E0100:01C65407] X-Spam-Score: 0.5 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: sip@ietf.org, jh@tutpro.com, christer.holmberg@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 Erkki, "sip-bounces@ietf.org" writes: Someone eats From line containing your nokia.com email. >Even if there could be two entries in the DNS for resolving primary >hosts and backup hosts, there is no hint given how the UA could find >or identify those two entries. Using the host part of the AOR according >to RFC 3263 leads the UA to possibly find multiple SRV records. However >according to RFC 2782 procedures only the preferred one (that responds) >should be selected and used. >So how to find those multiple proxies then ? >- Specify in the Outbound I-D that it would be possible to use > multiple SRV records simultaneously, unlike RFC 2782 states. > Similar handling could possibly be defined for DHCP SIP server > option. Use multiple NAPTR records? ;-o >- Specify a way to derive from the host part of AOR two different > names to resolve with DNS e.g. using a predefined prefix or postfix > to the original domain name to indicate SRV entries for backup >servers. >- Rely only to explicit configuration of those proxies e.g. with > configuration framework. I do not like this option too much as > it would cause extra trouble in deployment. Further it would > rely on a standard mechanism that is just not yet available > (or on a proprietary mechanism instead). >Any comments or better ideas ? As Aki said, use 3XX. If the route header in REGISTER does not contain proper URI, the outbound proxy could respond with, say, 305 listing the alternatives. Likewise, the registrar/home proxy could respond with 300 listing alternative registrars, and also return appropriate Service-Route in 2XX response. So, if we have Alice alice@hn.fi visiting vn.fi: A->O REGISTER sip:hn.fi SIP/2.0 To: alice@hn.fi Contact: sip:invalid.;reg-id=1;+sip.instance= "" Supported: path Route: O->A SIP/2.0 310 Use Outbound Proxies Contact: , A->O REGISTER sip:hn.fi SIP/2.0 To: alice@hn.fi Contact: sip:invalid.;reg-id=1;+sip.instance= "" Supported: path Route: Outbound proxy adds flow label to Path header: O->H REGISTER sip:hn.fi SIP/2.0 To: alice@hn.fi Contact: sip:invalid.;reg-id=1;+sip.instance= "" Require: path Path: H->O SIP/2.0 311 Alternative registrars Supported: path, outbound, gruu, pref Contact: , , ... A->O REGISTER sip:out1.hn.fi SIP/2.0 To: alice@hn.fi Contact: sip:invalid.;reg-id=1;+sip.instance= "" Supported: path Route: O->H REGISTER sip:hn.fi SIP/2.0 To: alice@hn.fi Contact: sip:invalid.;reg-id=1;+sip.instance= "" Require: path Path: H->O SIP/2.0 200 OK To: alice@hn.fi Contact: sip:invalid.;reg-id=1;+sip.instance= "" Supported: path, outbound, pref Path: Service-Route:, , ...followed by registrations via ob2.vn.fi to out2.hn.fi and via ob1.vn.fi to out3.hn.fi. OK. Weaknesses and open issues: - munging with route set is underdefined: what part of routes set the 3XX response replaces? - if we have N alternative outbound proxies and M registrars, how to combine them? - how to convert Path to Service-Route? Hm. Perhaps DNS is better, after all. --Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 11:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP0JU-0001ec-H0; Thu, 30 Mar 2006 11:48:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP0JT-0001eT-9F for sip@ietf.org; Thu, 30 Mar 2006 11:47:59 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP0JR-0005P7-V7 for sip@ietf.org; Thu, 30 Mar 2006 11:47:59 -0500 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2UGmTEl015672 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 30 Mar 2006 10:48:31 -0600 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1C23@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1C23@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sip-outbound Date: Thu, 30 Mar 2006 10:48:19 -0600 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Mar 30, 2006, at 6:17 AM, Christer Holmberg ((JO/LMF)) wrote: > > Hi Keith, > > I am not asking anyone to document the email exchange. I am simply > asking to document what happened at the meeting. > > And, if the only thing that was said at the meeting was "You have > seen the e-mail discussion, now let's vote" then please say so... > There was a brief recap of the positions raised on the list, with no new information that I could detect brought into the conversation. People had pretty much talked themselves through the issue on the list, I think. -- 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 Mar 30 16:45:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4vO-0006M5-VW; Thu, 30 Mar 2006 16:43:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4vN-0006M0-J6 for sip@ietf.org; Thu, 30 Mar 2006 16:43:25 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP4vM-00019A-92 for sip@ietf.org; Thu, 30 Mar 2006 16:43:25 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k2ULhLd3021074; Thu, 30 Mar 2006 14:43:22 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on location conveyance draft Date: Thu, 30 Mar 2006 14:43:21 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZSBWA0kXpRznMHSGW6/eNlgEmSQACPNY/w From: "Jean-Francois Mule" To: "James M. Polk" , "Dale R. Worley" , "McCalmont, Patti" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 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 James wrote: > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, March 27, 2006 6:16 PM > To: Dale R. Worley; McCalmont, Patti > Cc: Sip > Subject: RE: [Sip] comments on location conveyance draft >=20 > Dale and Patti >=20 > Brian Rosen and I are also writing the Emergency Phone BCP out of the > ECRIT > WG. How about, in the interests of keeping most emergency related > stuff in > ECRIT docs, that we make sure the Location Conveyance doc doesn't > prevent > this disabling, and the Phone BCP makes this disabling strictly > enforced > like you want? >=20 > This way your requirement is written where folks should know to look > for > emergency related features/functions, and we don't really cross WGs > too much. >=20 > I'm trying to maintain the balance I was told to maintain by one of > the new > RAI Area Directors that was at the ECRIT interim meeting (you can > guess > who) who reeeeeally wanted the Location doc to stay away from > emergency > related issues as much as possible. This is one I believe we can > directly > address in the Phone BCP doc to your liking. >=20 > Is this a fair compromise? Yes, not sure about fair but sounds like the place to put it. >=20 > Or do you two still want this explicit in the Location doc? No, again to me, this requirement does not belong in the sip location doc. > I also think we can add an informative reference in the location doc > to the > phone BCP doc for a pointer of where other work around this can be > found. The reverse is ok (pointer to sip loc in phone bcp) but adding more (informative) references to early BCP drafts in the sip loc conveyance draft is not a good idea imo. The hope is that SIP location conveyance can move faster than the ecrit phone bcp. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 16:53:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP53i-0001r4-79; Thu, 30 Mar 2006 16:52:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP53h-0001qz-81 for sip@ietf.org; Thu, 30 Mar 2006 16:52:01 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP53g-0001W5-Vs for sip@ietf.org; Thu, 30 Mar 2006 16:52:01 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k2ULpx6L023231; Thu, 30 Mar 2006 14:51:59 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on location conveyance draft Date: Thu, 30 Mar 2006 14:51:59 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZSBUGsDXT4ojZzQJa44qfFU+xxeQAcgEcgAHLx1lA= From: "Jean-Francois Mule" To: "McCalmont, Patti" , "James M. Polk" , "Dale R. Worley" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 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 Patti, You wrote: > James, >=20 > I'm not opposed to moving this into the BCP but would like to see the > following sentence re-written (last sentence before Section 7): >=20 > "This capability MUST be configurable, but is not RECOMMENDED as the > default configuration of any UA. Local policies will dictate this > ability." >=20 > Reword the "Local policies will dictate this ability." >=20 > To >=20 > "Local policies MUST be followed." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Is this proper use of RFC2119 requirement verbs? This change is not leading to a satisfactory requirement imo for at = least 2 reasons: 1/ How can an implementor meet this requirement other than providing = configuration settings to enable/disable the capability (hence the first = requirement is enough)? 2/ the wording leads to asking the question "by whom?": who should = follow local policies? Usually, seeking the subject of a passive = sentence for a requirement is an indication that it is hard to enforce = it, even more so in those context. To me, it is up to the end-users or = service provider -> leave this up to other national regulatory bodies to = enforce this as MUST... In short, I like the previous version better. Jean-Fran=E7ois _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 16:55:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP55H-0002Cj-4A; Thu, 30 Mar 2006 16:53:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP55G-0002Ce-MO for sip@ietf.org; Thu, 30 Mar 2006 16:53:38 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP55G-0001Yi-DE for sip@ietf.org; Thu, 30 Mar 2006 16:53:38 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k2ULraSm023596; Thu, 30 Mar 2006 14:53:37 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on location conveyance draft Date: Thu, 30 Mar 2006 14:53:36 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZSnBUlT/X7BegtR5aitUsL6v62BgBqDkJw From: "Jean-Francois Mule" To: "James M. Polk" , "McCalmont, Patti" , "Dale R. Worley" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 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 James wrote: > >"Local policies MUST be followed." >=20 > I'm ok with this. I don't believe this is a good change as-is. Jean-Fran=E7ois _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 18:05:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6BH-0002w0-Ts; Thu, 30 Mar 2006 18:03:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6BG-0002vu-2U for sip@ietf.org; Thu, 30 Mar 2006 18:03:54 -0500 Received: from hostr51.alcatel.com ([143.209.5.1] helo=aurfsy.aur.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP6BE-0004sM-LQ for sip@ietf.org; Thu, 30 Mar 2006 18:03:54 -0500 Received: from usrald00141 (localhost [127.0.0.1]) by aurfsy.aur.alcatel.com (8.11.6+Sun/8.11.3) with ESMTP id k2UN3mJ03486 for ; Thu, 30 Mar 2006 18:03:49 -0500 (EST) From: "Jim Li" To: Date: Thu, 30 Mar 2006 18:03:51 -0500 Message-ID: <007501c6544e$361cd7c0$8f0cd18f@ad3.ad.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZUTjVnkgYwEwQMTNy6t2M47CDQhA== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] Help Needed: Change DHCP Sip-Server-Address from Ip Address to Domain Name Syntax X-BeenThere: sip@ietf.org X-Mailman-Version: 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 DHCP Gurus, I need help on changing the option 120 sip-server-address from ip address to a domain name format. I've been using the ip address format just fine (below): option sip-server-address code 120 = string; option sip-server-address 1:0A:0A:0A:0A; I tried what RFC3361 suggested by changing the sip-server-address line like below: 1. option sip-server-address code 120 = string; option sip-server-address 0:7:example:3:com:0; 2. option sip-server-address code 120 = string; option sip-server-address 0:"example.com"; But both 1) & 2) failed. Could someone tell me if the syntax is correct? What part should I modify to make it work? Thanks in advance. Jim _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 30 23:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPB0s-00023t-Ml; Thu, 30 Mar 2006 23:13:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPB0p-00021u-3w; Thu, 30 Mar 2006 23:13:27 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPB0m-0002DA-OE; Thu, 30 Mar 2006 23:13:27 -0500 Received: from [192.168.0.105] ([71.240.162.175]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2V4D5W4008945 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 30 Mar 2006 22:13:06 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <03A46163-DFB6-4B76-8473-BF187AF4ED65@nostrum.com> References: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> <03A46163-DFB6-4B76-8473-BF187AF4ED65@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Thu, 30 Mar 2006 22:12:55 -0600 To: "sip@ietf.org WG" , Sipping WG , "simple@ietf.org list" , Sip-Implementors X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 71.240.162.175 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [Sip] SIPit 18 registration closes today (Friday 3/31) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Registration for SIPit 18 closes today (Friday 3/31). If you plan to attend but have not yet registered, please do so right away. Thanks, RjS On Feb 6, 2006, at 11:42 PM, Robert Sparks wrote: > Registration for SIPit 18 is open. > > This event will be held April 17-21 in > Akihabara, Tokyo, Japan. More information > about the event is available at http://www.sipit.net > and the host website at http://www.nic.ad.jp/en/sipit18/ > > Registration will close March 31. Please register early. > You can register now using https://www.regonline.com/88905 > > This 18th SIPForum SIPit is > > Hosted by: > - Japan Network Information Center (JPNIC) > > Co-hosted by: > - WIDE Project > - VoIP System Interoperability Task Force > > Supported by: > - Ministry of Internal Affairs and Communications (MIC) > - The Telecommunication Technology Committee (TTC) > - Telecom Service Association (TELESA) > - VoIP Forum Japan (VFJ) > - IPv6 Promotion Council (v6PC) > - ENUM Trial Japan (ETJP) > > Sponsors: > - Cisco Systems, Inc. > - Fractalist Inc. > - Fusion Communications Corporation > - Japan Telecom Co., Ltd. > - KDDI Corporation > - Mitsubishi Electric Information Network Corporation > - Mitsubishi Research Institute, Inc. > - NEC Corporation > - Netmarks Inc. > - Nippon Telegraph and Telephone Corporation > - Nippon Telegraph and Telephone East Corporation > - Nippon Telegraph and Telephone West Corporation > - NTT Advanced Technology Corporation > - Oki Electric Industry Co., Ltd. > - SoftBank BB Corp. > - Softfront > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 31 04:47:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPGC9-0003pq-Ua; Fri, 31 Mar 2006 04:45:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPGC8-0003pc-Lp; Fri, 31 Mar 2006 04:45:28 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPGC8-0007as-CQ; Fri, 31 Mar 2006 04:45:28 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2V9jPG16313; Fri, 31 Mar 2006 04:45:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Last Call: 'Management Information Base for the Session Initiation Protocol (SIP)' to Proposed Standard Date: Fri, 31 Mar 2006 03:45:21 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B35443F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Last Call: 'Management Information Base for the Session Initiation Protocol (SIP)' to Proposed Standard Thread-Index: AcZOxX7Paqe914BiQ4WrxfWRZ79G3AF4BO6Q From: "Samir Srivastava" To: , "IETF-Announce" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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, 1. It defines Object sipNotifSequenceNumber. It is defined for Manager to find a missing / out of sequence NOTIFICATION. Why not NOTIFICATIONS are stored in a table ? If Manager looses a notification, it cannot find which one is lost. Manager might poll this sequence, if it finds something missing, it can fetch from the table. If it is missing the latest Notification, then it is very important for the determining server health. Am I missing something ?=20 2. It defines "congested" as one of the value for sipServiceOperStatus. IMHO, Congestion is network property. It should be "overloaded" . Overload is server CPU stuff. If SIP server is finding congestion also based on retransmission etc, then shouldn't we have these two as distinct values. =20 3. As of now we know binary representation of overload/congestion is problem ? Shouldn't we have variable with % of overload. This MIB might be addressing 3261, it is a new requirement developing. So I am not that much concerned on this. Thx Samir =20 -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Thursday, March 23, 2006 12:59 PM To: IETF-Announce Cc: sip@ietf.org Subject: [Sip] Last Call: 'Management Information Base for the Session Initiation Protocol (SIP)' to Proposed Standard=20 The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Management Information Base for the Session Initiation Protocol (SIP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-10.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 From sip-bounces@ietf.org Fri Mar 31 07:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPINv-0007lf-8e; Fri, 31 Mar 2006 07:05:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPINu-0007lZ-Qy for sip@ietf.org; Fri, 31 Mar 2006 07:05:46 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPINt-0005tX-V8 for sip@ietf.org; Fri, 31 Mar 2006 07:05:46 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CB76CFDF; Fri, 31 Mar 2006 14:05:44 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Mar 2006 14:05:44 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Mar 2006 14:05:44 +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] comments on sip-connected-identity Date: Fri, 31 Mar 2006 14:05:43 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C41@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on sip-connected-identity Thread-Index: AcZTJvONCRB/f6XjTriDV6CrwUELCgBkiCHw From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Jesske, R" , , , , , "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 31 Mar 2006 12:05:44.0049 (UTC) FILETIME=[6FF39610:01C654BB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 The To header affects the transaction rules only in RFC2543 - in RFC3261 = it is not used - so if a client supporting dialogUriChange would have to = be RFC3216 compliant I see no problem with changing the header in the = response. Now, one can say that intermediate proxies may still be RFC2542 = compliant, but in that case you could have problems (with stateful = proxies) even if you change the URI in another request within the = dialog. The draft does not cover that. So, the question is really: how many proxies are there out there who = still use the To header URI from transaction identification? Also, a problem with UPDATE is that there is always a risk for race = conditions. For example, the UAC may send an UPDATE (e.g. to change = codecs and/or mode) itself when receving 200 OK, so if it RECEIVES an = UPDATE at the same time it will have to reject (491) that (I assume you = can not have two UPDATE transactons, even if one does not contain SDP). Regards, Christer -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: 29. maaliskuuta 2006 14:50 To: Jesske, R; audet@nortel.com; brett@broadsoft.com; Christer Holmberg = (JO/LMF); jdrosen@cisco.com; sip@ietf.org Subject: RE: [Sip] comments on sip-connected-identity Roland, Changing the From (or the To) URI in a response would undermine the = rules for transactions in SIP. It was stated during the SIP meeting at = IETF65 that we should not do this. So the alternative is to convey = information in some other header or body in the response. Feng Cao = addresses this in his response identity draft, although that received = some comments during IETF65 and will need to be reworked. The problem = always is whether the UAS can be authenticated - as I have stated = before, this is only if the request has been delivered over a TLS = connection over which the UA has already been authenticated. I suggest = you collaborate with Feng if you want this, but personally I am not = convinced that an adequate solution will be found. In the meantime we have a simple solution using connected-identity, = which in any case is needed for other situations. John > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: 29 March 2006 09:03 > To: audet@nortel.com; Elwell, John; brett@broadsoft.com;=20 > christer.holmberg@ericsson.com; jdrosen@cisco.com; sip@ietf.org > Subject: AW: [Sip] comments on sip-connected-identity >=20 > Sorry for bringing this again, why we have to use the UPDATE to get=20 > the connected identities with the changed From and to header? This is=20 > increasing SIP message flow for only sending a identity. >=20 > There could be also other possibilities. >=20 > Why not change the from in the 200 OK >=20 > or >=20 > define a new final Response like a 20X that is sent instead of the 200 = > OK --> Problem are the existing implementations. > Sending a 20x before a 200 (20x no provisional response) >=20 > or >=20 > define a new provisional response that is only used to send the=20 > regarding connected information (change of from header). >=20 > Best Regards >=20 > Roland >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Francois Audet [mailto:audet@nortel.com] > > Gesendet: Mittwoch, 29. M=E4rz 2006 03:14 > > An: Elwell, John; Brett Tate; Christer Holmberg; Jonathan Rosenberg; = > > IETF SIP List > > Betreff: RE: [Sip] comments on sip-connected-identity > >=20 > >=20 > > I should have said "session refresh" instead of "keep-alive". > >=20 > > > -----Original Message----- > > > From: Audet, Francois [SC100:3055:EXCH] > > > Sent: Tuesday, March 28, 2006 17:13 > > > To: 'Elwell, John'; 'Brett Tate'; 'Christer Holmberg'; 'Jonathan=20 > > > Rosenberg'; 'IETF SIP List' > > > Subject: RE: [Sip] comments on sip-connected-identity > > >=20 > > >=20 > > > RFC4028 (http://www.ietf.org/rfc/rfc4028.txt) describes the use of = > > > UPDATEs without Offers (in this case it is for keep-alive). > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: Monday, March 27, 2006 22:47 > > > > To: Brett Tate; 'Christer Holmberg'; 'Jonathan Rosenberg'; 'IETF = > > > > SIP List' > > > > Subject: RE: [Sip] comments on sip-connected-identity > > > >=20 > > > >=20 > > > > Brett, > > > >=20 > > > > I am getting confused by this thread. In my opinion Jonathan=20 > > > > clearly stated that UPDATE without SDP offer is allowed. > > > >=20 > > > > John > > > > > > >=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=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 Mar 31 07:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPIPw-0000mD-Dw; Fri, 31 Mar 2006 07:07:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPIPu-0000lr-NO for sip@ietf.org; Fri, 31 Mar 2006 07:07:50 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPIPu-00063F-6H for sip@ietf.org; Fri, 31 Mar 2006 07:07:50 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A13E6D9A; Fri, 31 Mar 2006 14:07:49 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Mar 2006 14:07:49 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Mar 2006 14:07: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-elwell-sip-connected-identity-01.txt Date: Fri, 31 Mar 2006 14:07:48 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C42@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-elwell-sip-connected-identity-01.txt Thread-Index: AcZQ8gtG5/KZjwshQTO21uKKFyl7SgDyWgOA From: "Christer Holmberg \(JO/LMF\)" To: "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 31 Mar 2006 12:07:49.0167 (UTC) FILETIME=[BA8713F0:01C654BB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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, I sent a mail within the "comments on sip-connected-identity" thread. I presented some issues with the current solution, but also pointed out that the draft currently does not talk about proxy impacts. Regards, Christer =20 -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: 26. maaliskuuta 2006 19:25 To: sip@ietf.org Subject: [Sip] draft-elwell-sip-connected-identity-01.txt (As chair) At the face-to-face meeting at IETF 65 we agreed that http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity- 01.txt formed the basis of part of our charter milestone to provide "Mechanism for Response Identity to IESG (PS). This mail is to confirm that decision using the list. If you have issues with this decision, please respond to this mail. Note: Please keep responses to this thread entirely separate to the thread on draft-cao-sip-response-identity regards Keith Keith Drage drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 31 08:26:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPJcL-0004UQ-8j; Fri, 31 Mar 2006 08:24:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPJcJ-0004Tp-Pi for sip@ietf.org; Fri, 31 Mar 2006 08:24:43 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPJcJ-0001dv-9K for sip@ietf.org; Fri, 31 Mar 2006 08:24:43 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IWZ00101UM0ZW@siemenscomms.co.uk> for sip@ietf.org; Fri, 31 Mar 2006 14:25:12 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IWZ0015TULZEO@siemenscomms.co.uk>; Fri, 31 Mar 2006 14:25:11 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 31 Mar 2006 14:24:38 +0100 Content-return: allowed Date: Fri, 31 Mar 2006 14:24:19 +0100 From: "Elwell, John" Subject: RE: [Sip] comments on sip-connected-identity To: "Christer Holmberg (JO/LMF)" Message-id: <50B1CBA96870A34799A506B2313F2667088D31A0@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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 Christer, See below. John=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 31 March 2006 13:06 > To: Elwell, John; Jesske, R; audet@nortel.com;=20 > brett@broadsoft.com; jdrosen@cisco.com; sip@ietf.org; Drage,=20 > Keith (Keith) > Subject: RE: [Sip] comments on sip-connected-identity >=20 >=20 > Hi, > =20 > The To header affects the transaction rules only in RFC2543 -=20 > in RFC3261 it is not used - so if a client supporting=20 > dialogUriChange would have to be RFC3216 compliant I see no=20 > problem with changing the header in the response. [JRE] You are correct. But some objection was raised at the meeting t= o changing the To header in a response compared to that in the request.= Does anyone remember? >=20 > Now, one can say that intermediate proxies may still be=20 > RFC2542 compliant, but in that case you could have problems=20 > (with stateful proxies) even if you change the URI in another=20 > request within the dialog. The draft does not cover that. [JRE] This was recognised in Vancouver. I will investigate whether mo= re words are needed in the next draft. >=20 > So, the question is really: how many proxies are there out=20 > there who still use the To header URI from transaction identificati= on? [JRE] If we don't change the To header URI in a response, transaction identification is not an issue. >=20 > Also, a problem with UPDATE is that there is always a risk=20 > for race conditions. For example, the UAC may send an UPDATE=20 > (e.g. to change codecs and/or mode) itself when receving 200=20 > OK, so if it RECEIVES an UPDATE at the same time it will have=20 > to reject (491) that (I assume you can not have two UPDATE=20 > transactons, even if one does not contain SDP). [JRE] The question of race conditions was touched on at the meeting a= nd was not thought to be a problem. If there is any impact of changing the T= o header field on race conditions, I will cover it in the next draft. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: 29. maaliskuuta 2006 14:50 > To: Jesske, R; audet@nortel.com; brett@broadsoft.com;=20 > Christer Holmberg (JO/LMF); jdrosen@cisco.com; sip@ietf.org > Subject: RE: [Sip] comments on sip-connected-identity >=20 > Roland, >=20 > Changing the From (or the To) URI in a response would=20 > undermine the rules for transactions in SIP. It was stated=20 > during the SIP meeting at IETF65 that we should not do this.=20 > So the alternative is to convey information in some other=20 > header or body in the response. Feng Cao addresses this in=20 > his response identity draft, although that received some=20 > comments during IETF65 and will need to be reworked. The=20 > problem always is whether the UAS can be authenticated - as I=20 > have stated before, this is only if the request has been=20 > delivered over a TLS connection over which the UA has already=20 > been authenticated. I suggest you collaborate with Feng if=20 > you want this, but personally I am not convinced that an=20 > adequate solution will be found. >=20 > In the meantime we have a simple solution using=20 > connected-identity, which in any case is needed for other situation= s. >=20 > John >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: 29 March 2006 09:03 > > To: audet@nortel.com; Elwell, John; brett@broadsoft.com;=20 > > christer.holmberg@ericsson.com; jdrosen@cisco.com; sip@ietf.org > > Subject: AW: [Sip] comments on sip-connected-identity > >=20 > > Sorry for bringing this again, why we have to use the UPDATE to g= et=20 > > the connected identities with the changed From and to=20 > header? This is=20 > > increasing SIP message flow for only sending a identity. > >=20 > > There could be also other possibilities. > >=20 > > Why not change the from in the 200 OK > >=20 > > or > >=20 > > define a new final Response like a 20X that is sent instead=20 > of the 200=20 > > OK --> Problem are the existing implementations. > > Sending a 20x before a 200 (20x no provisional response) > >=20 > > or > >=20 > > define a new provisional response that is only used to send the= =20 > > regarding connected information (change of from header). > >=20 > > Best Regards > >=20 > > Roland > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Francois Audet [mailto:audet@nortel.com] > > > Gesendet: Mittwoch, 29. M=E4rz 2006 03:14 > > > An: Elwell, John; Brett Tate; Christer Holmberg; Jonathan=20 > Rosenberg;=20 > > > IETF SIP List > > > Betreff: RE: [Sip] comments on sip-connected-identity > > >=20 > > >=20 > > > I should have said "session refresh" instead of "keep-alive". > > >=20 > > > > -----Original Message----- > > > > From: Audet, Francois [SC100:3055:EXCH] > > > > Sent: Tuesday, March 28, 2006 17:13 > > > > To: 'Elwell, John'; 'Brett Tate'; 'Christer Holmberg';=20 > 'Jonathan=20 > > > > Rosenberg'; 'IETF SIP List' > > > > Subject: RE: [Sip] comments on sip-connected-identity > > > >=20 > > > >=20 > > > > RFC4028 (http://www.ietf.org/rfc/rfc4028.txt) describes=20 > the use of=20 > > > > UPDATEs without Offers (in this case it is for keep-alive). > > > >=20 > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > > Sent: Monday, March 27, 2006 22:47 > > > > > To: Brett Tate; 'Christer Holmberg'; 'Jonathan=20 > Rosenberg'; 'IETF=20 > > > > > SIP List' > > > > > Subject: RE: [Sip] comments on sip-connected-identity > > > > >=20 > > > > >=20 > > > > > Brett, > > > > >=20 > > > > > I am getting confused by this thread. In my opinion Jonatha= n=20 > > > > > clearly stated that UPDATE without SDP offer is allowed. > > > > >=20 > > > > > John > > > > > > > > >=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 U= se=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 Fri Mar 31 08:34:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPJjV-0003cD-Cj; Fri, 31 Mar 2006 08:32:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPJjU-0003c3-Cy for sip@ietf.org; Fri, 31 Mar 2006 08:32:08 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPJjT-0001xL-CD for sip@ietf.org; Fri, 31 Mar 2006 08:32:08 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BFED74F002A; Fri, 31 Mar 2006 15:32:06 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Mar 2006 15:32:06 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Mar 2006 15:32: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on sip-connected-identity Date: Fri, 31 Mar 2006 15:32:05 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C4B@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on sip-connected-identity Thread-Index: AcZUxU0AnrDv223CS2auoh5D2QT54QAAJWTg From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , X-OriginalArrivalTime: 31 Mar 2006 13:32:05.0789 (UTC) FILETIME=[80825CD0:01C654C7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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 >The To header affects the transaction rules only in RFC2543 - in=20 >RFC3261 it is not used - so if a client supporting dialogUriChange=20 >would have to be RFC3216 compliant I see no problem with changing the=20 >header in the response. [JRE] You are correct. But some objection was raised at the meeting to = changing the To header in a response compared to that in the request. = Does anyone remember? >Now, one can say that intermediate proxies may still be >RFC2542 compliant, but in that case you could have problems (with=20 >stateful proxies) even if you change the URI in another request within=20 >the dialog. The draft does not cover that. [JRE] This was recognised in Vancouver. I will investigate whether more = words are needed in the next draft. [CHH] I do think we need to describe the proxy impacts. Because, as I = said, even if you don't change the To header URI per transaction, = chaning it within a dialog may cause problem in RFC2543 compliant = stateful proxies. And, again, if those proxies are "out of the scope" = (because we assume there are no such deployed), I see no reason why we = can't require the UAs supporting this extension being 3261 compliant and = change the To header URI within a transaction... >So, the question is really: how many proxies are there out there who=20 >still use the To header URI from transaction identification? [JRE] If we don't change the To header URI in a response, transaction = identification is not an issue. [CHH] No, but dialog identification may still be. >Also, a problem with UPDATE is that there is always a risk for race=20 >conditions. For example, the UAC may send an UPDATE (e.g. to change=20 >codecs and/or mode) itself when receving 200 OK, so if it RECEIVES an=20 >UPDATE at the same time it will have to reject (491) that (I assume=20 >you can not have two UPDATE transactons, even if one does not contain=20 >SDP). [JRE] The question of race conditions was touched on at the meeting and = was not thought to be a problem. If there is any impact of changing the = To header field on race conditions, I will cover it in the next draft. [CHH] I strongly disagree that race condition is not a problem. I could = present some IMS use-cases, but then I will just get a lots of = we-don't-care-about-your-walled-garden type of comments again. However, = I DO belive that even in the free and open internet world there could be = cases there UPDATE is sent after 200 OK. Also, I don't believe that the = chaning of To header itself is the race-condition problem, but the fact = that you have an UPDATE transaction race-condition. Regards, Christer > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 29. maaliskuuta 2006 14:50 > To: Jesske, R; audet@nortel.com; brett@broadsoft.com; Christer=20 > Holmberg (JO/LMF); jdrosen@cisco.com; sip@ietf.org > Subject: RE: [Sip] comments on sip-connected-identity >=20 > Roland, >=20 > Changing the From (or the To) URI in a response would undermine the=20 > rules for transactions in SIP. It was stated during the SIP meeting at = > IETF65 that we should not do this. > So the alternative is to convey information in some other header or=20 > body in the response. Feng Cao addresses this in his response identity = > draft, although that received some comments during IETF65 and will=20 > need to be reworked. The problem always is whether the UAS can be=20 > authenticated - as I have stated before, this is only if the request=20 > has been delivered over a TLS connection over which the UA has already = > been authenticated. I suggest you collaborate with Feng if you want=20 > this, but personally I am not convinced that an adequate solution will = > be found. >=20 > In the meantime we have a simple solution using connected-identity,=20 > which in any case is needed for other situations. >=20 > John >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: 29 March 2006 09:03 > > To: audet@nortel.com; Elwell, John; brett@broadsoft.com;=20 > > christer.holmberg@ericsson.com; jdrosen@cisco.com; sip@ietf.org > > Subject: AW: [Sip] comments on sip-connected-identity > >=20 > > Sorry for bringing this again, why we have to use the UPDATE to get=20 > > the connected identities with the changed From and to > header? This is > > increasing SIP message flow for only sending a identity. > >=20 > > There could be also other possibilities. > >=20 > > Why not change the from in the 200 OK > >=20 > > or > >=20 > > define a new final Response like a 20X that is sent instead > of the 200 > > OK --> Problem are the existing implementations. > > Sending a 20x before a 200 (20x no provisional response) > >=20 > > or > >=20 > > define a new provisional response that is only used to send the=20 > > regarding connected information (change of from header). > >=20 > > Best Regards > >=20 > > Roland > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Francois Audet [mailto:audet@nortel.com] > > > Gesendet: Mittwoch, 29. M=E4rz 2006 03:14 > > > An: Elwell, John; Brett Tate; Christer Holmberg; Jonathan > Rosenberg; > > > IETF SIP List > > > Betreff: RE: [Sip] comments on sip-connected-identity > > >=20 > > >=20 > > > I should have said "session refresh" instead of "keep-alive". > > >=20 > > > > -----Original Message----- > > > > From: Audet, Francois [SC100:3055:EXCH] > > > > Sent: Tuesday, March 28, 2006 17:13 > > > > To: 'Elwell, John'; 'Brett Tate'; 'Christer Holmberg'; > 'Jonathan > > > > Rosenberg'; 'IETF SIP List' > > > > Subject: RE: [Sip] comments on sip-connected-identity > > > >=20 > > > >=20 > > > > RFC4028 (http://www.ietf.org/rfc/rfc4028.txt) describes > the use of > > > > UPDATEs without Offers (in this case it is for keep-alive). > > > >=20 > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > > Sent: Monday, March 27, 2006 22:47 > > > > > To: Brett Tate; 'Christer Holmberg'; 'Jonathan > Rosenberg'; 'IETF > > > > > SIP List' > > > > > Subject: RE: [Sip] comments on sip-connected-identity > > > > >=20 > > > > >=20 > > > > > Brett, > > > > >=20 > > > > > I am getting confused by this thread. In my opinion Jonathan=20 > > > > > clearly stated that UPDATE without SDP offer is allowed. > > > > >=20 > > > > > John > > > > > > > > >=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=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 Mar 31 09:44:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPKpS-0004jg-FF; Fri, 31 Mar 2006 09:42:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPKpQ-0004gP-Ju; Fri, 31 Mar 2006 09:42:20 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPKpQ-0005X1-8k; Fri, 31 Mar 2006 09:42:20 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k2VEgJPb012813; Fri, 31 Mar 2006 07:42:19 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Last Call: 'Management Information Base for the SessionInitiation Protocol (SIP)' to Proposed Standard Date: Fri, 31 Mar 2006 07:42:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Last Call: 'Management Information Base for the SessionInitiation Protocol (SIP)' to Proposed Standard Thread-Index: AcZOxX7Paqe914BiQ4WrxfWRZ79G3AF4BO6QAAo9/jA= From: "Jean-Francois Mule" To: "Samir Srivastava" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: sip@ietf.org, klingle@cisco.com, iesg@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 Samir, Thank you for your comments - see responses inline. I removed the IETF-Announce recipient from the response to limit = spam; if it should be added back, feel free to forward or add it back. Jean-Francois --- Jean-Fran=E7ois Mul=E9 jfm@cablelabs.com=20 Samir Srivastava wrote: > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: Friday, March 31, 2006 2:45 AM > To: iesg@ietf.org; IETF-Announce > Cc: sip@ietf.org > Subject: RE: [Sip] Last Call: 'Management Information Base for the > SessionInitiation Protocol (SIP)' to Proposed Standard >=20 > Hi, >=20 > 1. It defines Object sipNotifSequenceNumber. It is defined for > Manager > to find a missing / out of > sequence NOTIFICATION. Why not NOTIFICATIONS are stored in a table ? > If > Manager looses a notification, it cannot find which one is lost. > Manager > might poll this sequence, if it finds something missing, it can fetch > from the table. If it is missing the latest Notification, then it is > very important for the determining server health. Am I missing > something > ? See the Notification Log MIB (RFC 3014) for a generic mechanism that can = be used for recording notification information. It can be used in = conjunction with the SIP MIB to store or log specific SIP MIB = notifications, hence addressing your question.=20 > 2. It defines "congested" as one of the value for > sipServiceOperStatus. > IMHO, Congestion is network property. It should be "overloaded" . > Overload is server CPU stuff. If SIP server is finding congestion also > based on retransmission etc, then shouldn't we have these two as > distinct values. See the I-D section on the relationship with other MIB modules and the = Network Services MIB (RFC 2788) in particular. RFC 2788 defines an applOperStatus object for the operational status of = the network service application with a valid value of congested(4), = hence the re-use of congested in the SIP MIB module. > 3. As of now we know binary representation of overload/congestion is > problem ? Shouldn't we have variable with % of overload. This MIB > might > be addressing 3261, it is a new requirement developing. So I am not > that > much concerned on this. I am not sure I get the point of your third comment, or the actual = requirement behind the proposed "variable with % of overload". But if = you are not much concerned on this, given that this version of the MIB = has undergone numerous revisions to address wg comments, completed WGLC, = and passed mib doctor review, I would recommend we do not increase the = scope of this version of the MIB module at this time. >=20 > Thx Thank you. The above responses should address your comments; if not, = please elaborate or explain. > Samir >=20 >=20 >=20 > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Thursday, March 23, 2006 12:59 PM > To: IETF-Announce > Cc: sip@ietf.org > Subject: [Sip] Last Call: 'Management Information Base for the Session > Initiation Protocol (SIP)' to Proposed Standard >=20 > The IESG has received a request from the Session Initiation Protocol > WG > to consider the following document: >=20 > - 'Management Information Base for the Session Initiation Protocol > (SIP) > ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-06. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-10.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 Mar 31 12:33:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPNTf-0005Bh-0D; Fri, 31 Mar 2006 12:32:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPNTd-0005Bc-J6 for sip@ietf.org; Fri, 31 Mar 2006 12:32:01 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPNTd-0004Nn-B1 for sip@ietf.org; Fri, 31 Mar 2006 12:32:01 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2VHVw1X025780; Fri, 31 Mar 2006 11:31:58 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 31 Mar 2006 18:31:58 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290845@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Christer Holmberg (JO/LMF)'" , sip@ietf.org Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt Date: Fri, 31 Mar 2006 18:31:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 The current decision is to see if http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.txt forms the basis of progressing as a WG item to fulfil our charter item. As such, it is still discussable and reviewable, but contents have to abide by WG decision, rather than author preference. The face-to-face meeting said it was, and we are looking to confirm that decision using the list. Does your comment indicate merely something missing that can be added, or does it indicate that the document is entirely in the wrong direction and therefore you object to the face-to-face meeting decision. regards Keith P.S. Reminder to all posters. Particularly when replying to specific questions we have asked, it helps if what you post actually constitutes an answer to the question. Mind reading does not yet constitute a qualification for a WG chair - we are still waiting for the relevant RFC to reach standards track before implementing. > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 31 March 2006 13:08 > To: Drage, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt > > > > Hi Keith, > > I sent a mail within the "comments on sip-connected-identity" > thread. I > presented some issues with the current solution, but also pointed out > that the draft currently does not talk about proxy impacts. > > Regards, > > Christer > > > > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 26. maaliskuuta 2006 19:25 > To: sip@ietf.org > Subject: [Sip] draft-elwell-sip-connected-identity-01.txt > > (As chair) > > At the face-to-face meeting at IETF 65 we agreed that > http://www.ietf.org/internet-drafts/draft-elwell-sip-connected -identity- 01.txt formed the basis of part of our charter milestone to provide "Mechanism for Response Identity to IESG (PS). This mail is to confirm that decision using the list. If you have issues with this decision, please respond to this mail. Note: Please keep responses to this thread entirely separate to the thread on draft-cao-sip-response-identity regards Keith Keith Drage drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 31 13:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPOG3-000669-EA; Fri, 31 Mar 2006 13:22:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPOG1-00065d-Jn for sip@ietf.org; Fri, 31 Mar 2006 13:22:01 -0500 Received: from [199.117.205.35] (helo=fwc-3b.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPOG1-0007kI-6l for sip@ietf.org; Fri, 31 Mar 2006 13:22:01 -0500 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] comments on location conveyance draft X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 31 Mar 2006 12:21:47 -0600 Message-ID: <422D410BD61FC04185076AD99AA7207A017DE3C1@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on location conveyance draft Thread-Index: AcZSBUGsDXT4ojZzQJa44qfFU+xxeQAcgEcgAHLx1lAAKug2gA== From: "McCalmont, Patti" To: "Jean-Francois Mule" , "James M. Polk" , "Dale R. Worley" X-OriginalArrivalTime: 31 Mar 2006 18:21:51.0313 (UTC) FILETIME=[FB16CC10:01C654EF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 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 In-line -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Thursday, March 30, 2006 3:52 PM To: McCalmont, Patti; James M. Polk; Dale R. Worley Cc: Sip Subject: RE: [Sip] comments on location conveyance draft Patti, You wrote: > James, >=20 > I'm not opposed to moving this into the BCP but would like to see the > following sentence re-written (last sentence before Section 7): >=20 > "This capability MUST be configurable, but is not RECOMMENDED as the > default configuration of any UA. Local policies will dictate this > ability." >=20 > Reword the "Local policies will dictate this ability." >=20 > To >=20 > "Local policies MUST be followed." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Is this proper use of RFC2119 requirement verbs? This change is not leading to a satisfactory requirement imo for at = least 2 reasons: 1/ How can an implementor meet this requirement other than providing = configuration settings to enable/disable the capability (hence the first = requirement is enough)? Configuration settings would work but have the addition to = prohibit disabling for emergency services. I see the dilemma as location = can change in a mobile environment to a country that allows location to = be withheld for emergency calls. 2/ the wording leads to asking the question "by whom?": who should = follow local policies? Usually, seeking the subject of a passive = sentence for a requirement is an indication that it is hard to enforce = it, even more so in those context. To me, it is up to the end-users or = service provider -> leave this up to other national regulatory bodies to = enforce this as MUST... I agree that it will be national regulatory bodies that do the = enforcement but the device must be capable of abiding by those = regulations.=20 In short, I like the previous version better. Jean-Fran=E7ois _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 31 14:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPP7h-0007Y9-J1; Fri, 31 Mar 2006 14:17:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPP7g-0007Wx-IA; Fri, 31 Mar 2006 14:17:28 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPP7g-0000gf-5X; Fri, 31 Mar 2006 14:17:28 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2VJHN924774; Fri, 31 Mar 2006 14:17:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Last Call: 'Management Information Base for the SessionInitiation Protocol (SIP)' to Proposed Standard Date: Fri, 31 Mar 2006 13:17:19 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B354B3D@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Last Call: 'Management Information Base for the SessionInitiation Protocol (SIP)' to Proposed Standard Thread-Index: AcZOxX7Paqe914BiQ4WrxfWRZ79G3AF4BO6QAAo9/jAACZ368A== From: "Samir Srivastava" To: "Jean-Francois Mule" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: sip@ietf.org, klingle@cisco.com, iesg@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 Jean-Francois, See in line. Thx Samir=20 -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Friday, March 31, 2006 6:42 AM To: Srivastava, Samir [SC100:8826:EXCH] Cc: sip@ietf.org; iesg@ietf.org; klingle@cisco.com Subject: RE: [Sip] Last Call: 'Management Information Base for the = SessionInitiation Protocol (SIP)' to Proposed Standard=20 Samir, Thank you for your comments - see responses inline. I removed the IETF-Announce recipient from the response to limit = spam; if it should be added back, feel free to forward or add it back. Jean-Francois --- Jean-Fran=E7ois Mul=E9 jfm@cablelabs.com=20 Samir Srivastava wrote: > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: Friday, March 31, 2006 2:45 AM > To: iesg@ietf.org; IETF-Announce > Cc: sip@ietf.org > Subject: RE: [Sip] Last Call: 'Management Information Base for the=20 > SessionInitiation Protocol (SIP)' to Proposed Standard >=20 > Hi, >=20 > 1. It defines Object sipNotifSequenceNumber. It is defined for > Manager > to find a missing / out of > sequence NOTIFICATION. Why not NOTIFICATIONS are stored in a table ? > If > Manager looses a notification, it cannot find which one is lost. > Manager > might poll this sequence, if it finds something missing, it can fetch=20 > from the table. If it is missing the latest Notification, then it is=20 > very important for the determining server health. Am I missing=20 > something ? See the Notification Log MIB (RFC 3014) for a generic mechanism that can = be used for recording notification information. It can be used in = conjunction with the SIP MIB to store or log specific SIP MIB = notifications, hence addressing your question.=20 SS>> Shouldn't 3014 referred somewhere ? > 2. It defines "congested" as one of the value for=20 > sipServiceOperStatus. > IMHO, Congestion is network property. It should be "overloaded" . > Overload is server CPU stuff. If SIP server is finding congestion also = > based on retransmission etc, then shouldn't we have these two as=20 > distinct values. See the I-D section on the relationship with other MIB modules and the = Network Services MIB (RFC 2788) in particular. RFC 2788 defines an applOperStatus object for the operational status of = the network service application with a valid value of congested(4), = hence the re-use of congested in the SIP MIB module. SS>> This I am leaving to working group to decide where it should be = fixed. For the future overload and congestion work, this looks to me = confusing and we should separate these two. > 3. As of now we know binary representation of overload/congestion is=20 > problem ? Shouldn't we have variable with % of overload. This MIB=20 > might be addressing 3261, it is a new requirement developing. So I am=20 > not that much concerned on this. I am not sure I get the point of your third comment, or the actual = requirement behind the proposed "variable with % of overload". But if = you are not much concerned on this, given that this version of the MIB = has undergone numerous revisions to address wg comments, completed WGLC, = and passed mib doctor review, I would recommend we do not increase the = scope of this version of the MIB module at this time. SS>> Refer the draft = http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-overload-reqs= -00.txt Section 5, page 11, REQ 7. And it was accepted widely and work needs to be continued on this. Even = if, we don't take this path, a separate object with % overload is good = enough. If we retain the binary nature, then it will be 0 or 1 value. >=20 > Thx Thank you. The above responses should address your comments; if not, = please elaborate or explain. > Samir >=20 >=20 >=20 > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Thursday, March 23, 2006 12:59 PM > To: IETF-Announce > Cc: sip@ietf.org > Subject: [Sip] Last Call: 'Management Information Base for the Session = > Initiation Protocol (SIP)' to Proposed Standard >=20 > The IESG has received a request from the Session Initiation Protocol=20 > WG to consider the following document: >=20 > - 'Management Information Base for the Session Initiation Protocol > (SIP) > ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits=20 > final comments on this action. Please send any comments to the=20 > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-06. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-10.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 Mar 31 14:58:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPPjq-0007Jo-Cv; Fri, 31 Mar 2006 14:56:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPPjo-0007Jj-BL for sip@ietf.org; Fri, 31 Mar 2006 14:56:52 -0500 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 1FPPjn-0001oi-Ut for sip@ietf.org; Fri, 31 Mar 2006 14:56:52 -0500 Received: from PTimmons [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A97202BC; Fri, 31 Mar 2006 14:56:34 -0500 From: "Patrick Timmons" To: "'Hadriel Kaplan'" , "'Jeroen van Bemmel'" , "'Cullen Jennings'" , "'Dean Willis'" , Subject: RE: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Date: Fri, 31 Mar 2006 13:56:37 -0600 Organization: Acme Packet, Inc. Message-ID: <008801c654fd$38866a30$800101df@acmepacket.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.2180 In-Reply-To: <034901c653e5$196196c0$6501a8c0@acmepacket.com> Thread-Index: AcZTwMPGDUWQGwRiSVGvT3vL31nJhAAE5f5QADkcE+A= X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: '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 Why not require that the UA send an OPTIONS request to its outbound proxy with Max-Forwards: 0? This jibes with the recommendations put forth in RFC 3261 (sec. 11) regarding querying capabilities of proxies: Alternatively, a server receiving an OPTIONS request with a Max- Forwards header field value of 0 MAY respond to the request regardless of the Request-URI. This behavior is common with HTTP/1.1. This behavior can be used as a "traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values. The edge proxy could reply to such a request with "Supported: outbound, keepalive-stun", or something along these lines. The registrar's support of sip-outbound could be queried similarly. This could be done either prior to, or immediately after initial registration. pt. -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Thursday, March 30, 2006 4:31 AM To: 'Jeroen van Bemmel'; 'Cullen Jennings'; 'Dean Willis'; sip@ietf.org Cc: 'Juha Heinanen' Subject: RE: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Hi Jeroen, The whole point is actually to make it a MUST that the UA perform a "safe" check, where "safe" means a sip-compliant check, before it does anything bad. It cannot be a choice of a sip-outbound compliant UA to just do bad if it wishes. It's not actually the outbound sip changes that are the big problem, it's really the binary/stun messages. I'm not overly worried about anyone sending new sip signaling - of course you can send that. Every new draft/RFC does that, and the beauty of SIP is to have that backwards-compatible flexibility. If the new sip-signaling needs to be understood by boxes that didn't have to understand it before because they may create issues for the legacy sip "network", well that's a problem from a SIP WG perspective I would think. And that is also a problem right now, perhaps, if a sip-outbound UA assumes the edge proxy is a sip-outbound proxy, when it is not. Right now the draft has no way to let the UA know the edge-proxy supports outbound. It has a way for it to know the registrar does, although even then it doesn't say that knowledge must be used for anything. The results of that may lead to constant forking, which is probably not a good thing. But the REAL problem is the UA can send a binary message. I understand why we want to do that, and although I hated the idea at first, I am willing to accept the decision and it's growing on me. BUT, it's still a major issue if UAs can send it when they like. They MUST safely check to make sure it's ok. It's not a major issue for my company - our products will handle it fine. But I can't speak for others. And not everyone who makes a sip-compliant proxy/registrar/UAS follows this mailing list. And people have all kinds of old software out there, which may be hard to upgrade. One only needs to look at the initial Protos test results to get an idea of the potential. Do we really want CERT Advisories issued, and the root cause being the IETF SIP Working Group??? Ironically, that would be good for firewall and SBC vendors - but not good for SIP. We have to do as much as possible to prevent it. -Hadriel > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Thursday, March 30, 2006 1:08 AM > To: Cullen Jennings; Dean Willis; sip@ietf.org > Cc: Juha Heinanen > Subject: Re: [Sip] How to indicate during proxy discovery that a > proxysupports"outbound" > > > On 3/25/06 1:53 PM, "Jeroen van Bemmel" wrote: > > > >> Could you explain why it is needed that the UA knows whether the > >> proxy supports outbound before sending its REGISTER request? > > > > So that we don't send things to the proxy that it does not understand. > > Some > > people did not care about this - some felt strongly about it. Some > pointed > > out that the proxy might black list a client that seemed to be > "attacking > > it" with bogus packets. > > The people that feel strongly about this could add 'Require: outbound' > to their request. Implementations that would blacklist such clients > would be considered broken. > > An alternative would perhaps be to depend on an authentication challenge: > first send a normal REGISTER, challenge, respond to the challenge and > if > Supported: outbound is there modify the request as needed. Not common > practice though... > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 31 15:00:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPPlm-0000RU-OG; Fri, 31 Mar 2006 14:58:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPPll-0000RP-7p for sip@ietf.org; Fri, 31 Mar 2006 14:58:53 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPPlj-0001u3-Vb for sip@ietf.org; Fri, 31 Mar 2006 14:58:53 -0500 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2VJwnWM089250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Mar 2006 13:58:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <442D89EB.6000907@nostrum.com> Date: Fri, 31 Mar 2006 13:58:35 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] draft-ietf-sip-outbound References: <5EB80D22825EEE42872083AD5BFFB5945D1C23@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1C23@esealmw113.eemea.ericsson.se> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Christer Holmberg (JO/LMF) wrote: >I am not asking anyone to document the email exchange. I am simply asking to document what happened at the meeting. > >And, if the only thing that was said at the meeting was "You have seen the e-mail discussion, now let's vote" then please say so... > > Christer: If you want to put together such a summary and post it to the mailing list for the sake of posterity, I'm fairly certain that no one would criticize you for it. Start here: http://videolab.uoregon.edu/events/ietf/ /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 31 15:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPQFT-0003kG-GD; Fri, 31 Mar 2006 15:29:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPQFS-0003k9-DH for sip@ietf.org; Fri, 31 Mar 2006 15:29:34 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPQFR-0004FO-PF for sip@ietf.org; Fri, 31 Mar 2006 15:29:34 -0500 Received: (qmail 12532 invoked by uid 0); 31 Mar 2006 20:29:27 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 31 Mar 2006 20:29:27 -0000 Message-ID: <003601c65501$cc44d870$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Patrick Timmons" , "'Hadriel Kaplan'" , "'Cullen Jennings'" , "'Dean Willis'" , References: <008801c654fd$38866a30$800101df@acmepacket.com> Subject: Re: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Date: Fri, 31 Mar 2006 22:29:23 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: '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 Patrick, Benefit of that is that it's nice and simple, drawback is an extra roundtrip. If you're willing to risk an extra roundtrip, you could do slightly better by adding Proxy-Require: outbound to the request, and specify proxy behavior similar to RFC3329. In particular, the edge proxy would be required to remove the Proxy-Require header if it supports outbound, and then forward the request (although RFC3261 table 2 does not allow a proxy to remove a Proxy-Require header, that is what is done). A non-supporting proxy would respond with an error, and the request could be retried without outbound. This approach would only give an extra roundtrip in case the edge proxy does not support outbound Regards, Jeroen ----- Original Message ----- From: "Patrick Timmons" To: "'Hadriel Kaplan'" ; "'Jeroen van Bemmel'" ; "'Cullen Jennings'" ; "'Dean Willis'" ; Cc: "'Juha Heinanen'" Sent: Friday, March 31, 2006 9:56 PM Subject: RE: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" > Why not require that the UA send an OPTIONS request to its outbound proxy > with Max-Forwards: 0? This jibes with the recommendations put forth in > RFC > 3261 (sec. 11) regarding querying capabilities of proxies: > > Alternatively, a server receiving an OPTIONS request with a Max- > Forwards header field value of 0 MAY respond to the request > regardless of the Request-URI. > > This behavior is common with HTTP/1.1. This behavior can be used > as a "traceroute" functionality to check the capabilities of > individual hop servers by sending a series of OPTIONS requests > with incremented Max-Forwards values. > > The edge proxy could reply to such a request with "Supported: outbound, > keepalive-stun", or something along these lines. > > The registrar's support of sip-outbound could be queried similarly. This > could be done either prior to, or immediately after initial registration. > > pt. > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Thursday, March 30, 2006 4:31 AM > To: 'Jeroen van Bemmel'; 'Cullen Jennings'; 'Dean Willis'; sip@ietf.org > Cc: 'Juha Heinanen' > Subject: RE: [Sip] How to indicate during proxy discovery that > aproxysupports"outbound" > > Hi Jeroen, > The whole point is actually to make it a MUST that the UA perform a "safe" > check, where "safe" means a sip-compliant check, before it does anything > bad. It cannot be a choice of a sip-outbound compliant UA to just do bad > if > it wishes. It's not actually the outbound sip changes that are the big > problem, it's really the binary/stun messages. > > I'm not overly worried about anyone sending new sip signaling - of course > you can send that. Every new draft/RFC does that, and the beauty of SIP > is > to have that backwards-compatible flexibility. If the new sip-signaling > needs to be understood by boxes that didn't have to understand it before > because they may create issues for the legacy sip "network", well that's a > problem from a SIP WG perspective I would think. And that is also a > problem > right now, perhaps, if a sip-outbound UA assumes the edge proxy is a > sip-outbound proxy, when it is not. Right now the draft has no way to let > the UA know the edge-proxy supports outbound. It has a way for it to know > the registrar does, although even then it doesn't say that knowledge must > be > used for anything. The results of that may lead to constant forking, > which > is probably not a good thing. > > But the REAL problem is the UA can send a binary message. I understand > why > we want to do that, and although I hated the idea at first, I am willing > to > accept the decision and it's growing on me. BUT, it's still a major issue > if UAs can send it when they like. They MUST safely check to make sure > it's > ok. > > It's not a major issue for my company - our products will handle it fine. > But I can't speak for others. And not everyone who makes a sip-compliant > proxy/registrar/UAS follows this mailing list. And people have all kinds > of > old software out there, which may be hard to upgrade. One only needs to > look at the initial Protos test results to get an idea of the potential. > > Do we really want CERT Advisories issued, and the root cause being the > IETF > SIP Working Group??? Ironically, that would be good for firewall and SBC > vendors - but not good for SIP. We have to do as much as possible to > prevent it. > > -Hadriel > > >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: Thursday, March 30, 2006 1:08 AM >> To: Cullen Jennings; Dean Willis; sip@ietf.org >> Cc: Juha Heinanen >> Subject: Re: [Sip] How to indicate during proxy discovery that a >> proxysupports"outbound" >> >> > On 3/25/06 1:53 PM, "Jeroen van Bemmel" wrote: >> > >> >> Could you explain why it is needed that the UA knows whether the >> >> proxy supports outbound before sending its REGISTER request? >> > >> > So that we don't send things to the proxy that it does not understand. >> > Some >> > people did not care about this - some felt strongly about it. Some >> pointed >> > out that the proxy might black list a client that seemed to be >> "attacking >> > it" with bogus packets. >> >> The people that feel strongly about this could add 'Require: outbound' >> to their request. Implementations that would blacklist such clients >> would be considered broken. >> >> An alternative would perhaps be to depend on an authentication challenge: >> first send a normal REGISTER, challenge, respond to the challenge and >> if >> Supported: outbound is there modify the request as needed. Not common >> practice though... >> >> 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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 31 17:54:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSUN-0001wT-7M; Fri, 31 Mar 2006 17:53:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSUL-0001wN-5V for sip@ietf.org; Fri, 31 Mar 2006 17:53:05 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPSUJ-0002M9-TI for sip@ietf.org; Fri, 31 Mar 2006 17:53:05 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 31 Mar 2006 14:53:04 -0800 X-IronPort-AV: i="4.03,152,1141632000"; d="scan'208"; a="265905242:sNHT31208408" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2VMr2Yg001030; Fri, 31 Mar 2006 14:53:02 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 31 Mar 2006 22:53:02 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 31 Mar 2006 14:53:02 -0800 Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt From: Cullen Jennings To: Juha Heinanen Message-ID: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZVFd0sG9YDgsEJEdqlkgARJEEJ/A== In-Reply-To: <17451.32493.130932.496483@harjus.tutpro.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "sip@ietf.org" , Aki Niemi , 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 3/29/06 10:47 PM, "Juha Heinanen" wrote: > Cullen Jennings writes: > >> As we agreed in the meeting, I would rather have these is separate >> documents since we can move forward with the what you do with it now and >> solve the many possible way beyond configuration how you might find it >> later. > > it is fine to have a separate document describing how SIP UA finds > outbound-proxy-set, but that separate document MUST be referenced in the > outbound I-D in the same way as rfc3263 is referenced by rfc3261. there > is no point to publish a document where the only standards based way to > configure outbound-proxy-set is manually, because no regular user is > able to do it correctly. I think you and I mean different things by the word "configuration". I was not suggesting that end users would be typing several URIs into a phone using a 9 digit key pad - I completely agree with you that this would never happen in any scaleable 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 Fri Mar 31 17:55:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSUV-00021F-0P; Fri, 31 Mar 2006 17:53:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSUT-0001xg-Mo for sip@ietf.org; Fri, 31 Mar 2006 17:53:13 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPSUS-0002MN-9w for sip@ietf.org; Fri, 31 Mar 2006 17:53:13 -0500 Received: from [64.101.173.195] ([64.101.173.195]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k2VMripf022017 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 31 Mar 2006 16:53:45 -0600 In-Reply-To: <003601c65501$cc44d870$31713b51@BEMBUSTER> References: <008801c654fd$38866a30$800101df@acmepacket.com> <003601c65501$cc44d870$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v746.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Date: Fri, 31 Mar 2006 16:53:33 -0600 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'Cullen Jennings' , sip@ietf.org, 'Juha Heinanen' , Patrick Timmons X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mar 31, 2006, at 2:29 PM, Jeroen van Bemmel wrote: > Patrick, > > Benefit of that is that it's nice and simple, drawback is an extra > roundtrip. If you're willing to risk an extra roundtrip, you could > do slightly better by adding Proxy-Require: outbound to the > request, and specify proxy behavior similar to RFC3329. In > particular, the edge proxy would be required to remove the Proxy- > Require header if it supports outbound, and then forward the > request (although RFC3261 table 2 does not allow a proxy to remove > a Proxy-Require header, that is what is done). A non-supporting > proxy would respond with an error, and the request could be retried > without outbound. > Having a proxy eat a proxy-require seems as much of a violation of SIP as having a proxy ignore a proxy-require as the PING proponents proposed. Perhaps not a good idea from the perspective of protocol purity. But the OPTIONS probe seems like it might work. -- 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 Mar 31 18:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSq5-0002wv-RJ; Fri, 31 Mar 2006 18:15:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSq3-0002wW-TB for sip@ietf.org; Fri, 31 Mar 2006 18:15:31 -0500 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 1FPSq2-0003QF-HC for sip@ietf.org; Fri, 31 Mar 2006 18:15:31 -0500 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A8010174; Fri, 31 Mar 2006 18:15:13 -0500 Message-ID: <001b01c65518$f9222b60$800101df@acmepacket.com> From: "Bob Penfield" To: "Dean Willis" , "Jeroen van Bemmel" References: <008801c654fd$38866a30$800101df@acmepacket.com><003601c65501$cc44d870$31713b51@BEMBUSTER> Subject: Re: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" Date: Fri, 31 Mar 2006 18:15:17 -0500 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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'Cullen Jennings' , sip@ietf.org, 'Juha Heinanen' , Patrick Timmons X-BeenThere: sip@ietf.org X-Mailman-Version: 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 had the same thought about proxies eating Proxy-Require values. But then prompted by Jeroen's mention of RFC 3329, I took a look and found this in Section 2.3.1 on page 8. .... and the server is a proxy, it MUST remove the "sec-agree" value from both the Require and Proxy-Require header fields, and then remove the header fields if no values remain. I seems reasonable to me that an extension that would use a Proxy-Require tag might only apply to the first-hop proxy, as is the case with Security Agreement and outbound (for the edge proxy behavior). It also seems reasonable to me that if no other proxies along the path need to understand the extension, that the proxy doing the extension could remove the tag from the Proxy-Require header. Given the precedent set in RFC 3329, we should consider that option. For outbound, we need two option tags. One which corresponds to the first-hop edge proxy behavior (i.e. the STUN ping) that would be in a Proxy-Require header, and one which corresponds to the registrar behavior (sip-instance and reg-id's) that would be in the Require header. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Dean Willis" > > On Mar 31, 2006, at 2:29 PM, Jeroen van Bemmel wrote: > >> Patrick, >> >> Benefit of that is that it's nice and simple, drawback is an extra >> roundtrip. If you're willing to risk an extra roundtrip, you could do >> slightly better by adding Proxy-Require: outbound to the request, and >> specify proxy behavior similar to RFC3329. In particular, the edge proxy >> would be required to remove the Proxy- Require header if it supports >> outbound, and then forward the request (although RFC3261 table 2 does >> not allow a proxy to remove a Proxy-Require header, that is what is >> done). A non-supporting proxy would respond with an error, and the >> request could be retried without outbound. >> > > Having a proxy eat a proxy-require seems as much of a violation of SIP as > having a proxy ignore a proxy-require as the PING proponents proposed. > Perhaps not a good idea from the perspective of protocol purity. > > But the OPTIONS probe seems like it might work. > > -- > 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 Mar 31 20:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPUxR-00067A-1Y; Fri, 31 Mar 2006 20:31:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPUxP-00065W-AN for sip@ietf.org; Fri, 31 Mar 2006 20:31:15 -0500 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 1FPUxM-0002za-QT for sip@ietf.org; Fri, 31 Mar 2006 20:31:15 -0500 Received: from PTimmons [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A7D30284; Fri, 31 Mar 2006 20:30:59 -0500 From: "Patrick Timmons" To: "'Jeroen van Bemmel'" , "'Hadriel Kaplan'" , "'Cullen Jennings'" , "'Dean Willis'" , Subject: RE: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" Date: Fri, 31 Mar 2006 20:31:03 -0500 Organization: Acme Packet, Inc. Message-ID: <00fb01c6552b$f0bef940$800101df@acmepacket.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.2180 In-Reply-To: <003601c65501$cc44d870$31713b51@BEMBUSTER> Thread-Index: AcZVAdX7SE5vyHXVRdKn62Hj/JysbAAKAwNA X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: '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 Jeroen - Ah, I wasn't aware that RFC3329 legitimized stripping Proxy-Require headers for edge proxies. Thanks for the reference. However -- in a general sense, the issue here is that the UA needs to know specific features as they pertain to the topology of the network; i.e., that the *edge* supports 'outbound'. My sense is that it's perfectly reasonable to think that there will be requirements for UAs to know specific features of proxies that sit topologically off of the edge (?-CSCF, for example). In this case, the Proxy-Require technique breaks down... and we're left with supporting two different methods for achieving (essentially) the same ends. For features that are specific to the edge proxy like sec-agree and outbound this approach clearly works at least as efficiently as an additional round-trip. I'm certainly not opposed to using the technique, since RFC3329 set the precedent that it is okay to do so. But it seems that using OPTIONS to query the options of a device is putting the protocol to its intended use; as to whether this virtue is worth the extra round-trip is open for debate I suppose. Maybe I'll go back and read the archives -- this must have come up before during the development of RFC3329, which was before my time. pt. -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Friday, March 31, 2006 3:29 PM To: Patrick Timmons; 'Hadriel Kaplan'; 'Cullen Jennings'; 'Dean Willis'; sip@ietf.org Cc: 'Juha Heinanen' Subject: Re: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" Patrick, Benefit of that is that it's nice and simple, drawback is an extra roundtrip. If you're willing to risk an extra roundtrip, you could do slightly better by adding Proxy-Require: outbound to the request, and specify proxy behavior similar to RFC3329. In particular, the edge proxy would be required to remove the Proxy-Require header if it supports outbound, and then forward the request (although RFC3261 table 2 does not allow a proxy to remove a Proxy-Require header, that is what is done). A non-supporting proxy would respond with an error, and the request could be retried without outbound. This approach would only give an extra roundtrip in case the edge proxy does not support outbound Regards, Jeroen ----- Original Message ----- From: "Patrick Timmons" To: "'Hadriel Kaplan'" ; "'Jeroen van Bemmel'" ; "'Cullen Jennings'" ; "'Dean Willis'" ; Cc: "'Juha Heinanen'" Sent: Friday, March 31, 2006 9:56 PM Subject: RE: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" > Why not require that the UA send an OPTIONS request to its outbound > proxy with Max-Forwards: 0? This jibes with the recommendations put > forth in RFC > 3261 (sec. 11) regarding querying capabilities of proxies: > > Alternatively, a server receiving an OPTIONS request with a Max- > Forwards header field value of 0 MAY respond to the request > regardless of the Request-URI. > > This behavior is common with HTTP/1.1. This behavior can be used > as a "traceroute" functionality to check the capabilities of > individual hop servers by sending a series of OPTIONS requests > with incremented Max-Forwards values. > > The edge proxy could reply to such a request with "Supported: > outbound, keepalive-stun", or something along these lines. > > The registrar's support of sip-outbound could be queried similarly. > This could be done either prior to, or immediately after initial registration. > > pt. > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Thursday, March 30, 2006 4:31 AM > To: 'Jeroen van Bemmel'; 'Cullen Jennings'; 'Dean Willis'; > sip@ietf.org > Cc: 'Juha Heinanen' > Subject: RE: [Sip] How to indicate during proxy discovery that > aproxysupports"outbound" > > Hi Jeroen, > The whole point is actually to make it a MUST that the UA perform a "safe" > check, where "safe" means a sip-compliant check, before it does > anything bad. It cannot be a choice of a sip-outbound compliant UA to > just do bad if it wishes. It's not actually the outbound sip changes > that are the big problem, it's really the binary/stun messages. > > I'm not overly worried about anyone sending new sip signaling - of > course you can send that. Every new draft/RFC does that, and the > beauty of SIP is to have that backwards-compatible flexibility. If > the new sip-signaling needs to be understood by boxes that didn't have > to understand it before because they may create issues for the legacy > sip "network", well that's a problem from a SIP WG perspective I would > think. And that is also a problem right now, perhaps, if a > sip-outbound UA assumes the edge proxy is a sip-outbound proxy, when > it is not. Right now the draft has no way to let the UA know the > edge-proxy supports outbound. It has a way for it to know the > registrar does, although even then it doesn't say that knowledge must > be used for anything. The results of that may lead to constant > forking, which is probably not a good thing. > > But the REAL problem is the UA can send a binary message. I > understand why we want to do that, and although I hated the idea at > first, I am willing to accept the decision and it's growing on me. > BUT, it's still a major issue if UAs can send it when they like. They > MUST safely check to make sure it's ok. > > It's not a major issue for my company - our products will handle it fine. > But I can't speak for others. And not everyone who makes a > sip-compliant proxy/registrar/UAS follows this mailing list. And > people have all kinds of old software out there, which may be hard to > upgrade. One only needs to look at the initial Protos test results to > get an idea of the potential. > > Do we really want CERT Advisories issued, and the root cause being the > IETF SIP Working Group??? Ironically, that would be good for firewall > and SBC vendors - but not good for SIP. We have to do as much as > possible to prevent it. > > -Hadriel > > >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: Thursday, March 30, 2006 1:08 AM >> To: Cullen Jennings; Dean Willis; sip@ietf.org >> Cc: Juha Heinanen >> Subject: Re: [Sip] How to indicate during proxy discovery that a >> proxysupports"outbound" >> >> > On 3/25/06 1:53 PM, "Jeroen van Bemmel" wrote: >> > >> >> Could you explain why it is needed that the UA knows whether the >> >> proxy supports outbound before sending its REGISTER request? >> > >> > So that we don't send things to the proxy that it does not understand. >> > Some >> > people did not care about this - some felt strongly about it. Some >> pointed >> > out that the proxy might black list a client that seemed to be >> "attacking >> > it" with bogus packets. >> >> The people that feel strongly about this could add 'Require: outbound' >> to their request. Implementations that would blacklist such clients >> would be considered broken. >> >> An alternative would perhaps be to depend on an authentication challenge: >> first send a normal REGISTER, challenge, respond to the challenge and >> if >> Supported: outbound is there modify the request as needed. Not common >> practice though... >> >> 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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Mar 31 23:25:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPXeU-0008UL-M1; Fri, 31 Mar 2006 23:23:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPXeS-0008UG-P0 for sip@ietf.org; Fri, 31 Mar 2006 23:23:52 -0500 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 1FPXeR-0001ZQ-GR for sip@ietf.org; Fri, 31 Mar 2006 23:23:52 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A04A0174; Fri, 31 Mar 2006 23:23:38 -0500 From: "Hadriel Kaplan" To: "'Dean Willis'" , "'Jeroen van Bemmel'" Subject: RE: [Sip] How to indicate during proxy discovery that aproxysupports"outbound" Date: Fri, 31 Mar 2006 23:23:45 -0500 Message-ID: <01b501c65544$116e5ba0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVFd+ORPMQpaubTbGpphoDXQ54wwAIRK/Q In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'Cullen Jennings' , sip@ietf.org, 'Juha Heinanen' , 'Patrick Timmons' X-BeenThere: sip@ietf.org X-Mailman-Version: 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: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, March 31, 2006 5:54 PM > > Having a proxy eat a proxy-require seems as much of a violation of > SIP as having a proxy ignore a proxy-require as the PING proponents > proposed. Perhaps not a good idea from the perspective of protocol > purity. I thought we were trying to avoid that whole debate again, no? :) Considering everything else this draft changes, for proxies and registrars, one can hardly talk about "violation of SIP" and "protocol purity". ;) Nor did all PING proponents propose having a proxy ignore a proxy-require, and they shouldn't have - it wouldn't have needed to. -hadriel p.s. I am now firmly a STUN believer, but I only joined this list recently and read through the archive and when one looks at the argument exchange, in hindsight I think it's fairly comical _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip