From john.elwell@siemens-enterprise.com Fri May 1 00:09:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC793A69E8 for ; Fri, 1 May 2009 00:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySDIeuqT6dFW for ; Fri, 1 May 2009 00:09:37 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 3F90D3A699E for ; Fri, 1 May 2009 00:09:37 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KIY00F8JEM8QE@siemenscomms.co.uk> for sipcore@ietf.org; Fri, 01 May 2009 08:10:56 +0100 (BST) Date: Fri, 01 May 2009 08:10:54 +0100 From: "Elwell, John" In-reply-to: <49FA32E9.3070509@cisco.com> To: Paul Kyzivat , Hans Erik van Elburg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnJ6q7eceTjT3M4Qk6MW/zas1ijHgAPivnA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FA32E9.3070509@cisco.com> Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 07:09:38 -0000 Paul, I am not disagreeing with you, but a consequence of this analysis is that many option tags, or the way they are intended to be used, guarantee very little when they appear in Supported. The only time an option tag has real meaning in Supported is when it appears in a request to mean that the UAS can safely use that capability when responding. Examples of option tags used differently from this: - norefersub - its use in one request means that the UA is capable of accepting a subsequent REFER request without implicit subscription; - join/replaces - use of either of these in one request indicates that the UA would support the respective header field if received in another request; - from-change - use in one request indicates support for this feature in subsequent requests on that dialog; - eventlist - use in a SUBSCRIBE request indicates support for this feature in received NOTIFY requests on dialogs created from that SUBSCRIBE request; - answermode - use in a REGISTER request indicates support for this feature in a received INVITE request. Even if there are no absolute guarantees, there is a general expectation that things will work if used in the way described in the RFC where the option tag is defined. For example, if receipt of a replaces option tag does not mean that the Replaces header field is likely to be supported if received in future request from outside the dialog, things like attended call transfer would not work with any degree of reliability. So I think the scope of an option tag is defined by the RFC where the option tag is defined. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 01 May 2009 00:23 > To: Hans Erik van Elburg > Cc: SIPCORE > Subject: Re: [sipcore] Question on Require in responses >=20 >=20 >=20 > Hans Erik van Elburg wrote: > >=20 > > Dean Willis wrote: > >> The option tag is a means of 1) discovering whether or not=20 > the far-end=20 > >> supports a specific extension and of 2) declaring the=20 > criticality of=20 > >> understanding that extension relative to satisfying a=20 > request and 3)=20 > >> informing the UAC of what extensions were applied to the=20 > request in=20 > >> order to generate the response. This is purely a function of=20 > >> capability negotiation, not one of invocation. > >> > >> The extension itself (typically, an extension header=20 > field, although=20 > >> there are other types of extensions) is what causes the=20 > extension to=20 > >> be invoked. > > Depends a bit how you define extension, but I would argue that if I=20 > > require an extension to be supported on a=20 > transaction/dialog by the UAS=20 > > and the UAS accepts the request that this means that for=20 > this call the=20 > > UAS behaves as it should according to the extensions specification. >=20 > There are several issues in what you say above: >=20 > "if I require an extension to be supported on a=20 > transaction/*dialog* by=20 > the UAS" >=20 > supported for a transaction, and supported for a dialog are two very=20 > different things. We certainly don't have a way to say=20 > whether you want=20 > one or the other. >=20 > These headers were derived from http, and there they really=20 > only apply=20 > for one transaction. Nominally that is all they mean for sip too. >=20 > In practice, particular features really have a broader scope=20 > than that,=20 > but there is little/no formality about that. >=20 > "if... and the UAS accepts the request that means that *for=20 > this call*=20 > the UAS behaves as it should according to the extensions=20 > specification" >=20 > There you have assumed that the scope is, depending on your=20 > terminology, > - the call > - the session > - the dialog > - the dialog usage >=20 > But in general you cannot assume that. The support may cease=20 > on the next=20 > transaction, explicitly or implicitly. It is far from clear that=20 > support, or requirements to support, continue if not restated=20 > in every=20 > transaction. Nor is there any guarantee that support, if indicated in=20 > the response to a transaction, will continue even momentarily=20 > before the=20 > next transaction. >=20 > And of course there is no guarantee that features that are=20 > indicated as=20 > supported in response to an OPTIONS will continue to be=20 > supported when a=20 > call is made to the same address. >=20 > Thanks, > Paul >=20 > > Saying that an extensions invokes itself is meaningless to me. > >=20 > > A UAS may choose to only invoke the extension behaviour if=20 > it finds that=20 > > the extension is required. That comes close to saying that the=20 > > require:extension invokes the behaviour in the UAS, but it=20 > is not at all=20 > > the same. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Fri May 1 05:52:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755C828C12B for ; Fri, 1 May 2009 05:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ADiC4b-c70V for ; Fri, 1 May 2009 05:52:12 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 17B3828C1A3 for ; Fri, 1 May 2009 05:51:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,278,1238976000"; d="scan'208";a="43179578" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 May 2009 12:53:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n41CrDKF016860; Fri, 1 May 2009 08:53:13 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n41CrDrN019724; Fri, 1 May 2009 12:53:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 08:53:13 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 08:53:13 -0400 Message-ID: <49FAF0AC.9030008@cisco.com> Date: Fri, 01 May 2009 08:53:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FA32E9.3070509@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2009 12:53:13.0250 (UTC) FILETIME=[C9C16820:01C9CA5B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5674; t=1241182393; x=1242046393; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=FvID1cPzBGTzomL6DFtRckez/Nwvh8B8xU6OcVDhOSA=; b=eHA9CLvoPye3hXXbO7WK6DG7SRGHZlCl53wq95oYd+Ao4QPRW8IRbmhfY6 E0YjjKUYB3uyBi0qYrHdXDYpKmWvPNgKjwkOVKRV/f0x9NkkzbfjkV/EJdT/ izklQuNR/w; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 12:52:13 -0000 John, I'm not trying to assert that the situation is a good one. But I have been trying to achieve a general understanding that you cannot, currently, infer too much from these headers. Do so and you will set yourself up for disappointment. Perhaps we should work define the scope for these things, and where appropriate specify that it is more extensive than a single transaction. But I think it will be impossible to make any commitments that much of anything has dialog scope. I think the most we can hope for is: this remains true until a change is signaled. Thanks, Paul Elwell, John wrote: > Paul, > > I am not disagreeing with you, but a consequence of this analysis is > that many option tags, or the way they are intended to be used, > guarantee very little when they appear in Supported. The only time an > option tag has real meaning in Supported is when it appears in a request > to mean that the UAS can safely use that capability when responding. > Examples of option tags used differently from this: > - norefersub - its use in one request means that the UA is capable of > accepting a subsequent REFER request without implicit subscription; > - join/replaces - use of either of these in one request indicates that > the UA would support the respective header field if received in another > request; > - from-change - use in one request indicates support for this feature in > subsequent requests on that dialog; > - eventlist - use in a SUBSCRIBE request indicates support for this > feature in received NOTIFY requests on dialogs created from that > SUBSCRIBE request; > - answermode - use in a REGISTER request indicates support for this > feature in a received INVITE request. > > Even if there are no absolute guarantees, there is a general expectation > that things will work if used in the way described in the RFC where the > option tag is defined. For example, if receipt of a replaces option tag > does not mean that the Replaces header field is likely to be supported > if received in future request from outside the dialog, things like > attended call transfer would not work with any degree of reliability. > > So I think the scope of an option tag is defined by the RFC where the > option tag is defined. > > John > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 01 May 2009 00:23 >> To: Hans Erik van Elburg >> Cc: SIPCORE >> Subject: Re: [sipcore] Question on Require in responses >> >> >> >> Hans Erik van Elburg wrote: >>> Dean Willis wrote: >>>> The option tag is a means of 1) discovering whether or not >> the far-end >>>> supports a specific extension and of 2) declaring the >> criticality of >>>> understanding that extension relative to satisfying a >> request and 3) >>>> informing the UAC of what extensions were applied to the >> request in >>>> order to generate the response. This is purely a function of >>>> capability negotiation, not one of invocation. >>>> >>>> The extension itself (typically, an extension header >> field, although >>>> there are other types of extensions) is what causes the >> extension to >>>> be invoked. >>> Depends a bit how you define extension, but I would argue that if I >>> require an extension to be supported on a >> transaction/dialog by the UAS >>> and the UAS accepts the request that this means that for >> this call the >>> UAS behaves as it should according to the extensions specification. >> There are several issues in what you say above: >> >> "if I require an extension to be supported on a >> transaction/*dialog* by >> the UAS" >> >> supported for a transaction, and supported for a dialog are two very >> different things. We certainly don't have a way to say >> whether you want >> one or the other. >> >> These headers were derived from http, and there they really >> only apply >> for one transaction. Nominally that is all they mean for sip too. >> >> In practice, particular features really have a broader scope >> than that, >> but there is little/no formality about that. >> >> "if... and the UAS accepts the request that means that *for >> this call* >> the UAS behaves as it should according to the extensions >> specification" >> >> There you have assumed that the scope is, depending on your >> terminology, >> - the call >> - the session >> - the dialog >> - the dialog usage >> >> But in general you cannot assume that. The support may cease >> on the next >> transaction, explicitly or implicitly. It is far from clear that >> support, or requirements to support, continue if not restated >> in every >> transaction. Nor is there any guarantee that support, if indicated in >> the response to a transaction, will continue even momentarily >> before the >> next transaction. >> >> And of course there is no guarantee that features that are >> indicated as >> supported in response to an OPTIONS will continue to be >> supported when a >> call is made to the same address. >> >> Thanks, >> Paul >> >>> Saying that an extensions invokes itself is meaningless to me. >>> >>> A UAS may choose to only invoke the extension behaviour if >> it finds that >>> the extension is required. That comes close to saying that the >>> require:extension invokes the behaviour in the UAS, but it >> is not at all >>> the same. >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From eburger@standardstrack.com Fri May 1 06:13:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3662F3A7225 for ; Fri, 1 May 2009 06:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRIWtL1VqSQC for ; Fri, 1 May 2009 06:13:20 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 9CC7828C17B for ; Fri, 1 May 2009 06:10:50 -0700 (PDT) Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157] helo=[192.168.45.103]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LzsXA-0005x1-4F; Fri, 01 May 2009 06:12:09 -0700 Message-Id: From: Eric Burger To: Attila Sipos In-Reply-To: <680808427CF931459462C3D78CB5EC6005739F71@EXVS02.nasstar-t1.net> Content-Type: multipart/signed; boundary=Apple-Mail-262-883323807; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 09:12:08 -0400 References: <680808427CF931459462C3D78CB5EC6005739F71@EXVS02.nasstar-t1.net> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIPCORE Subject: Re: [sipcore] info-03 draft and "session negotiation exchange" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 13:13:21 -0000 --Apple-Mail-262-883323807 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Section 3 is where "negotiation" occurs. I put negotiation in quotes because it is an advertising model, not an offer/answer model. Would changing negotiation language to advertising language reduce confusion, or is it semantic dressing? On Apr 30, 2009, at 2:30 AM, Attila Sipos wrote: > Hi, > > Sorry for questions late in the day but I'm not clear on the > negotiation methods of the info package draft. > > The draft mentions "session negotiation exchange" several times. > > Can someone tell me where this is defined? > > Section 3.1 (UA Behavior) shows INVITE/OK/ACK as an exchange. > > I see from section "5.2. INFO Headers" of the "INFO tables" e-mail > that PRACK and UPDATE are allowed to carry the Recv-Info header. So > what is the "exchange" if say, INVITE and PRACK are involved? > > From section 3.1, it seems that the initial "offer" is in the INVITE > and then "confirmed" in the ACK. So if PRACK is received, can one > "confirm" in a PRACK? > > Also, if Recv-Info is allowed in UPDATE, how does that get > "confirmed"? > Or is it that UPDATE just lists the packages already negotiated? > > Or is it that package renegotiation is only ever done in > INVITE/re-INVITE? > If so, I would like to see some text explicitly stating this. > If not, what renegotiation combinations are there? > > Then there is this... > The limitation on requiring the negotiation to occur within the > context of a session negotiation exchange means that if the > initiating UA issues a re-INVITE (after the above ACK) with the > following. > > INVITE ... > ... > Recv-Info: P, R, T > ... > > The target UA MUST NOT send any package P INFO methods until the > target UA sees P in the final ACK from the initiating UA. > > > So, let's say P was being sent by the target. Then when the > re-INVITE arrives, P has to be stopped (or queued), until P is > seen again in the ACK. > > So what happens if there is a re-INVITE/INFO(package P) crossover? > I think we need to say that if the initiating UA receives the INFO > for package P, it should either: > 1. still process it as normal > or > 2. issue a 4xx response (something like 491 Request Pending) > so that the package P event can be re-attempted once the ACK > has been received. > > Regards, > > Attila > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-262-883323807 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1MDExMzEyMDlaMCMGCSqGSIb3 DQEJBDEWBBRTVn+qzqQpioITaeqhSP6qSnIlNjCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQCxqWVlhW/3tF2MLns6py05ztjmbm2YsVZfHEoCJnSNli8J mfkRxdMdOrxeIKLm/jewjqsr3/P9f71QsqHgrQOwITvWN/mKjWjdorwan9CfoRXFrp28ayM3axrQ uaBwfwuv7q6JLKXy/schel+PvnBTLwAUH8PW1Cw16d+KEipzJEwr9WI9b6Zs+Ee6cbYLkvDVCoff EVp3rBxvoA4N84b1AnougZvI1F8Qcz4NSQk/hlqJAbzw3zkqlMY1u27aYBvp9srnrBPjT1IKViLj K8j7GdgHem3xLTQ09bmmp0Mwht046615kOC+771Qoa0jlf9/Pg95dJd9AcigOmancfeQAAAAAAAA --Apple-Mail-262-883323807-- From ietf.hanserik@gmail.com Fri May 1 07:44:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E94E28C1F4 for ; Fri, 1 May 2009 07:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvI2+GaX-ujl for ; Fri, 1 May 2009 07:44:53 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id ED7DE28C1EF for ; Fri, 1 May 2009 07:44:52 -0700 (PDT) Received: by ewy24 with SMTP id 24so2468090ewy.37 for ; Fri, 01 May 2009 07:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oIxw8UKzJ1RY4wJADxHmKQoLgAV/ekxAdPYo4fy5KXE=; b=bcVMvTa9D5+98H+SPEbUIZMHmOPYIa0C4NbXi1QtE+OqDvx2NzQYlGMA91zN8q5UAb UP7A3mQFZ3ny4rUkPlVYJljk7oTpctxGn2gIRNdk/YoUHmxkWPT0ah56yq/QMleLZ0W0 4uE3enBo572RT7IujxiyUCJx/kkUxuuitGvkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X3IUqvssEE7ZZ8aALmmTp9mplHCzE7EPjBx0ry0Z00ciAIlz0xpUxVlrhwCiS9/p/7 yrTtYqyx566CRysLW13BjB5wLwO+Ca2fkmTlqgjWBVNXVrZcKK3AG/xQ1VG217pYxXNK D7wJ/lW86TiUqK9qCrtssXToGtiik7zhMb3wg= MIME-Version: 1.0 Received: by 10.216.1.202 with SMTP id 52mr863815wed.15.1241189175803; Fri, 01 May 2009 07:46:15 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FA32E9.3070509@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 1 May 2009 16:46:15 +0200 Message-ID: <9ae56b1e0905010746g233b991bg35d9e66d21c1804c@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=00163646db76ec40560468dadf8d Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 14:44:58 -0000 --00163646db76ec40560468dadf8d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes. /Hans Erik van Elburg On Fri, May 1, 2009 at 9:10 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Paul, > > I am not disagreeing with you, but a consequence of this analysis is > that many option tags, or the way they are intended to be used, > guarantee very little when they appear in Supported. The only time an > option tag has real meaning in Supported is when it appears in a request > to mean that the UAS can safely use that capability when responding. > Examples of option tags used differently from this: > - norefersub - its use in one request means that the UA is capable of > accepting a subsequent REFER request without implicit subscription; > - join/replaces - use of either of these in one request indicates that > the UA would support the respective header field if received in another > request; > - from-change - use in one request indicates support for this feature in > subsequent requests on that dialog; > - eventlist - use in a SUBSCRIBE request indicates support for this > feature in received NOTIFY requests on dialogs created from that > SUBSCRIBE request; > - answermode - use in a REGISTER request indicates support for this > feature in a received INVITE request. > > Even if there are no absolute guarantees, there is a general expectation > that things will work if used in the way described in the RFC where the > option tag is defined. For example, if receipt of a replaces option tag > does not mean that the Replaces header field is likely to be supported > if received in future request from outside the dialog, things like > attended call transfer would not work with any degree of reliability. > > So I think the scope of an option tag is defined by the RFC where the > option tag is defined. > > John > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 01 May 2009 00:23 > > To: Hans Erik van Elburg > > Cc: SIPCORE > > Subject: Re: [sipcore] Question on Require in responses > > > > > > > > Hans Erik van Elburg wrote: > > > > > > Dean Willis wrote: > > >> The option tag is a means of 1) discovering whether or not > > the far-end > > >> supports a specific extension and of 2) declaring the > > criticality of > > >> understanding that extension relative to satisfying a > > request and 3) > > >> informing the UAC of what extensions were applied to the > > request in > > >> order to generate the response. This is purely a function of > > >> capability negotiation, not one of invocation. > > >> > > >> The extension itself (typically, an extension header > > field, although > > >> there are other types of extensions) is what causes the > > extension to > > >> be invoked. > > > Depends a bit how you define extension, but I would argue that if I > > > require an extension to be supported on a > > transaction/dialog by the UAS > > > and the UAS accepts the request that this means that for > > this call the > > > UAS behaves as it should according to the extensions specification. > > > > There are several issues in what you say above: > > > > "if I require an extension to be supported on a > > transaction/*dialog* by > > the UAS" > > > > supported for a transaction, and supported for a dialog are two very > > different things. We certainly don't have a way to say > > whether you want > > one or the other. > > > > These headers were derived from http, and there they really > > only apply > > for one transaction. Nominally that is all they mean for sip too. > > > > In practice, particular features really have a broader scope > > than that, > > but there is little/no formality about that. > > > > "if... and the UAS accepts the request that means that *for > > this call* > > the UAS behaves as it should according to the extensions > > specification" > > > > There you have assumed that the scope is, depending on your > > terminology, > > - the call > > - the session > > - the dialog > > - the dialog usage > > > > But in general you cannot assume that. The support may cease > > on the next > > transaction, explicitly or implicitly. It is far from clear that > > support, or requirements to support, continue if not restated > > in every > > transaction. Nor is there any guarantee that support, if indicated in > > the response to a transaction, will continue even momentarily > > before the > > next transaction. > > > > And of course there is no guarantee that features that are > > indicated as > > supported in response to an OPTIONS will continue to be > > supported when a > > call is made to the same address. > > > > Thanks, > > Paul > > > > > Saying that an extensions invokes itself is meaningless to me. > > > > > > A UAS may choose to only invoke the extension behaviour if > > it finds that > > > the extension is required. That comes close to saying that the > > > require:extension invokes the behaviour in the UAS, but it > > is not at all > > > the same. > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > --00163646db76ec40560468dadf8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes.

/Hans Erik van Elburg


On Fri, May 1, 2009 at 9:10 AM, Elwell, = John <john.elwell@siemens-enterprise.com> wrote:
Paul,

I am not disagreeing with you, but a consequence of this analysis is
that many option tags, or the way they are intended to be used,
guarantee very little when they appear in Supported. The only time an
option tag has real meaning in Supported is when it appears in a request to mean that the UAS can safely use that capability when responding.
Examples of option tags used differently from this:
- norefersub - its use in one request means that the UA is capable of
accepting a subsequent REFER request without implicit subscription;
- join/replaces - use of either of these in one request indicates that
the UA would support the respective header field if received in another
request;
- from-change - use in one request indicates support for this feature in subsequent requests on that dialog;
- eventlist - use in a SUBSCRIBE request indicates support for this
feature in received NOTIFY requests on dialogs created from that
SUBSCRIBE request;
- answermode - use in a REGISTER request indicates support for this
feature in a received INVITE request.

Even if there are no absolute guarantees, there is a general expectation that things will work if used in the way described in the RFC where the
option tag is defined. For example, if receipt of a replaces option tag
does not mean that the Replaces header field is likely to be supported
if received in future request from outside the dialog, things like
attended call transfer would not work with any degree of reliability.

So I think the scope of an option tag is defined by the RFC where the
option tag is defined.

John

> -----Original Message-----
> From: sipcore-bounces@ietf= .org
> [mailto:sipcore-bounces@ie= tf.org] On Behalf Of Paul Kyzivat
> Sent: 01 May 2009 00:23
> To: Hans Erik van Elburg
> Cc: SIPCORE
> Subject: Re: [sipcore] Question on Require in responses
>
>
>
> Hans Erik van Elburg wrote: > >
> > Dean Willis wrote:
> >> The option tag is a means of 1) discovering whether or not > the far-end
> >> supports a specific extension and of 2) declaring the
> criticality of
> >> understanding that extension relative to satisfying a
> request and 3)
> >> informing the UAC of what extensions were applied to the
> request in
> >> order to generate the response. This is purely a function of<= br> > >> capability negotiation, not one of invocation.
> >>
> >> The extension itself (typically, an extension header
> field, although
> >> there are other types of extensions) is what causes the
> extension to
> >> be invoked.
> > Depends a bit how you define extension, but I would argue that if= I
> > require an extension to be supported on a
> transaction/dialog by the UAS
> > and the UAS accepts the request that this means that for
> this call the
> > UAS behaves as it should according to the extensions specificatio= n.
>
> There are several issues in what you say above:
>
> "if I require an extension to be supported on a
> transaction/*dialog* by
> the UAS"
>
> supported for a transaction, and supported for a dialog are two very > different things. We certainly don't have a way to say
> whether you want
> one or the other.
>
> These headers were derived from http, and there they really
> only apply
> for one transaction. Nominally that is all they mean for sip too.
>
> In practice, particular features really have a broader scope
> than that,
> but there is little/no formality about that.
>
> "if... and the UAS accepts the request that means that *for
> this call*
> the UAS behaves as it should according to the extensions
> specification"
>
> There you have assumed that the scope is, depending on your
> terminology,
> - the call
> - the session
> - the dialog
> - the dialog usage
>
> But in general you cannot assume that. The support may cease
> on the next
> transaction, explicitly or implicitly. It is far from clear that
> support, or requirements to support, continue if not restated
> in every
> transaction. Nor is there any guarantee that support, if indicated in<= br> > the response to a transaction, will continue even momentarily
> before the
> next transaction.
>
> And of course there is no guarantee that features that are
> indicated as
> supported in response to an OPTIONS will continue to be
> supported when a
> call is made to the same address.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
> > Saying that an extensions invokes itself is meaningless to me. > >
> > A UAS may choose to only invoke the extension behaviour if
> it finds that
> > the extension is required. That comes close to saying that the > > require:extension invokes the behaviour in the UAS, but it
> is not at all
> > the same.
>
> ________________________= _______________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

--00163646db76ec40560468dadf8d-- From ietf.hanserik@gmail.com Fri May 1 08:07:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F683A6845 for ; Fri, 1 May 2009 08:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLiQA3uAX5e5 for ; Fri, 1 May 2009 08:06:58 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 21A483A70EA for ; Fri, 1 May 2009 08:06:57 -0700 (PDT) Received: by ewy24 with SMTP id 24so2477753ewy.37 for ; Fri, 01 May 2009 08:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=o58+1vDjx2SKawqXJ/ouvmanr8Z4XAh7ceRe5vfn64w=; b=lDxa4M1X5JzuDGYlXVdsjnFahKGPx+5w1AGupuZlKH42Qm7jvla2JmWzAsjQbL+++e nkR+jGpSaYLYkjpddROWyHNTmOwkdK4UWDy9OQ3VKdmSByJi/xtwICwFFDWZH1LKWA2e YiBcqVrCT23kEppO9gX3h6kliXIKPrOmrK7ic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SYEmTrGiJ8SGmMzGK+vvDp1ydGmvasS/hNIyhP7pco7VNWlkELSSoeKKwkWuGHPLsy FgB7/cGH9H/Nnz0Za5AIzHnduTU2L+R+WKoRIkSeQ+kYmpPqxy6OfwdbILSX8s9v/iAC EjvDVwCM3/ashISJjIKWeMGjVyG/saM/eBP2g= MIME-Version: 1.0 Received: by 10.216.45.78 with SMTP id o56mr858935web.152.1241190501163; Fri, 01 May 2009 08:08:21 -0700 (PDT) In-Reply-To: <49FA50CD.1080406@softarmor.com> References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> Date: Fri, 1 May 2009 17:08:21 +0200 Message-ID: <9ae56b1e0905010808s50a236dcge61b9f8250dfec9@mail.gmail.com> From: Hans Erik van Elburg To: Dean Willis Content-Type: multipart/alternative; boundary=0016367b6de6eba32f0468db2e49 Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 15:07:00 -0000 --0016367b6de6eba32f0468db2e49 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It is not clear what you are disagreeing with. Because I agree that "the goal is to make the information that was encoded into the requestURI (and maybe as modified by intermediates, that use case is open) available to the UAS.". But this is a little imprecise as it doen't distinguish between the Request-URI as it was crafted initially by the UAC and those that came about due to request URI rewrites that happened because of routing and those that happened due to the communication being redirected/forwarded to another user then the one originally addressed. If UA A sends an INVITE to URI of user B, but this call is forwarded on the way to URI of user C. Then to C the Request URI value that was used by the forwarding entity (URI of user C) is more relevant URI to decide how it will render the call to the user then the URI of user B. /Hans Erik van Elburg On Fri, May 1, 2009 at 3:30 AM, Dean Willis wrote: > Hans Erik van Elburg wrote: > > > > > > Dean Willis wrote: > >> > >> On Apr 30, 2009, at 4:38 AM, Hans Erik van Elburg wrote: > >> > >>> Overloading in general is not a good design strategy, why do you > >>> think that trying to mold everything (diversion/history info) into > >>> Request URI is a good idea?? > >> > >> The reason that we're having this conversation is that we have > >> proposals, History-Info being one, for 1) putting our parameters in to > >> the original request-URI, and 2) recovering that original request-URI > >> after it has been contact-routed (and otherwise mangled) so that the > >> parameters can be used at the UAS. > >> > >> So the presumption exists that the original request URI is useful to > >> the UAS. SIP did, and now SIPCORE has, a chartered item for making > >> that happen. > >> > >> I'm trying to back up and make sure that we know WHY we're trying to > >> deliver the original request URI to the UAS, and then asking if some > >> other approach that meets the same requirements might actually be > >> easier to do. > >> > > That is fine of course, but the point is that we are not talking about > > delivering parameters to an application, but about recovering a complete > > URI that has gone lost on the way. > > but why exactly do we need to recover the URI? What is it that is > special about the URI or is likely to get used in some useful sort of > way downstream? If it isn't the "Request URI-ness" that is important, > maybe we can find some more convenient way to deliver that information. > > > >>> The problem here is that this information has nothing to do with > >>> application invocation, but tells something about how the signalling > >>> reached the callee (target). And this information is only relevant to > >>> the callee if that decides that it is. > >> > >> > >> That's a profound philosophical assertion. HTTP, for example, makes no > >> consideration for "how the signaling reaches the target" in > >> determining how to process a request. The fact that some think SIP > >> should take this into consideration indicates to me that we have a > >> layering problem in our design. > >> > > I don't think SIP and HTTP are comparable at all in this respect. In > > HTTP you directly address the server that you like to get (post, delete, > > update) information from. In SIP you adress the URI of a user, that will > > lead you to the home proxy in most cases and which is then forwarded to > > the UAS by overwriting the Request URI. > > Well, HTTP has proxies too, and SIP were originally intended to be > comparable. > > '> No layering problem, just a flaw in SIP's design that causes usefull > > information to be destroyed for no good reason. We're just trying to fix > > that, no more no less. > >> From one perspective, this makes the application invocation implicit; > >> the UAS has to guess what to do based on clues sprinkled throughout > >> the communication and across several layers of the ISO stack. It's > >> much better to have this sort of determination made based on explicit > >> indicators at a single application layer. > >> > > No. The goal of the target-uri discussion is to have all the relevant > > target-uri information readily available in the SIP request received by > > the UAS. That is all on the same OSI layer, layer 7. > > > > I disgaree -- the goal is to make the information that was encoded into > the requestURI (and maybe as modified by intermediates, that use case is > open) available to the UAS. > > > -- > dean > --0016367b6de6eba32f0468db2e49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is not clear what you are disagreeing with. Because I agree that "t= he goal is to make the information that was encoded into the requestURI (an= d maybe as modified by intermediates, that use case is open) available to t= he UAS.".

But this is a little imprecise as it doen't distinguish between the= Request-URI as it was crafted initially by the UAC and those that came abo= ut due to request URI rewrites that happened because of routing and those t= hat=A0 happened due to the communication being redirected/forwarded to anot= her user then the one originally addressed.=A0

If UA A sends an INVITE to URI of user B, but this call is forwarded on= the way to URI of user C. Then to C the Request URI value that was used by= the forwarding entity (URI of user C) is more relevant URI to decide how i= t will render the call to the user then the URI of user B.

/Hans Erik van Elburg

On Fri, May 1, 2009 at 3:30 AM, Dean Willis = <dean.wil= lis@softarmor.com> wrote:
Hans Erik van Elburg wrote:
>
>
> Dean Willis wrote:
>>
>> On Apr 30, 2009, at 4:38 AM, Hans Erik van Elburg wrote:
>>
>>> Overloading in general is not a good design strategy, why do y= ou
>>> think that trying to mold everything (diversion/history info) = into
>>> Request URI is a good idea??
>>
>> The reason that we're having this conversation is that we have=
>> proposals, History-Info being one, for 1) putting our parameters i= n to
>> the original request-URI, and 2) recovering that original request-= URI
>> after it has been contact-routed (and otherwise mangled) so that t= he
>> parameters can be used at the UAS.
>>
>> So the presumption exists that the original request URI is useful = to
>> the UAS. SIP did, and now SIPCORE has, a chartered item for making=
>> that happen.
>>
>> I'm trying to back up and make sure that we know WHY we're= trying to
>> deliver the original request URI to the UAS, and then asking if so= me
>> other approach that meets the same requirements might actually be<= br> >> easier to do.
>>
> That is fine of course, but the point is that we are not talking about=
> delivering parameters to an application, but about recovering a comple= te
> URI that has gone lost on the way.

but why exactly do we need to recover the URI? What is it that is
special about the URI or is likely to get used in some useful sort of
way downstream? If it isn't the "Request URI-ness" that is im= portant,
maybe we can find some more convenient way to deliver that information.


>>> The problem here is that this information has nothing to do wi= th
>>> application invocation, but tells something about how the sign= alling
>>> reached the callee (target). And this information is only rele= vant to
>>> the callee if that decides that it is.
>>
>>
>> That's a profound philosophical assertion. HTTP, for example, = makes no
>> consideration for "how the signaling reaches the target"= in
>> determining how to process a request. The fact that some think SIP=
>> should take this into consideration indicates to me that we have a=
>> layering problem in our design.
>>
> I don't think SIP and HTTP are comparable at all in this respect. = In
> HTTP you directly address the server that you like to get (post, delet= e,
> update) information from. In SIP you adress the URI of a user, that wi= ll
> lead you to the home proxy in most cases and which is then forwarded t= o
> the UAS by overwriting the Request URI.

Well, HTTP has proxies too, and SIP were originally intended to be comparable.

'> No layering problem, just a flaw in SIP's design that causes = usefull
> information to be destroyed for no good reason. We&#= 39;re just trying to fix
> that, no more no less.
>> From one perspective, this makes the application invocation implic= it;
>> the UAS has to guess what to do based on clues sprinkled throughou= t
>> the communication and across several layers of the ISO stack. It&#= 39;s
>> much better to have this sort of determination made based on expli= cit
>> indicators at a single application layer.
>>
> No. The goal of the target-uri discussion is to have all the relevant<= br> > target-uri information readily available in the SIP request received b= y
> the UAS. That is all on the same OSI layer, layer 7.
>

I disgaree -- the goal is to make the information that was encoded in= to
the requestURI (and maybe as modified by intermediates, that use case is open) available to the UAS.


--
dean

--0016367b6de6eba32f0468db2e49-- From jmh@joelhalpern.com Fri May 1 08:59:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EBDF3A70E1 for ; Fri, 1 May 2009 08:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HB24qVUHvBW for ; Fri, 1 May 2009 08:59:46 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F1F033A6D18 for ; Fri, 1 May 2009 08:59:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EF0A3430230 for ; Fri, 1 May 2009 09:01:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A9BD5430202 for ; Fri, 1 May 2009 09:01:08 -0700 (PDT) Message-ID: <49FB1CC2.5060802@joelhalpern.com> Date: Fri, 01 May 2009 12:01:06 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: SIPCORE References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> <9ae56b1e0905010808s50a236dcge61b9f8250dfec9@mail.gmail.com> In-Reply-To: <9ae56b1e0905010808s50a236dcge61b9f8250dfec9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 15:59:47 -0000 Actually, the redirect case (when not done via an error to the originating UAC and retry from there) seems to get at the problem. The original user specified a URI they were trying to reach, and some parameters. Some of those parameters would still apply after the redirect, but some probably don't. But it appears likely that no one knows which parameters are which. And the redirector may have some parameter information to add. And depending upon how everything was understood, and why it was being redirected, the destination of the redirect may or may not care about the original URI (may even care about the user part of the original URI) in full, in order to decide what to do (the voicemail examples.) All of which leads to ??? From where I sit, it leads back to H-I since in theory at least with History-Info you can reconstruct any of the information you want. Maybe not easily. But given that we have completely unspecified behaviors with regard to parameters and their preservation, and given that even the user part from the original request URI may be useful to the target, and any parameters that were added in the middle may be useful, ... If we could be sure that all we wanted was original and final, then maybe there would be something we could do, but I am quite sure we can make more complicated realistic cases where that will not suffice. Joel Hans Erik van Elburg wrote: > It is not clear what you are disagreeing with. Because I agree that "the > goal is to make the information that was encoded into the requestURI > (and maybe as modified by intermediates, that use case is open) > available to the UAS.". > > But this is a little imprecise as it doen't distinguish between the > Request-URI as it was crafted initially by the UAC and those that came > about due to request URI rewrites that happened because of routing and > those that happened due to the communication being redirected/forwarded > to another user then the one originally addressed. > > If UA A sends an INVITE to URI of user B, but this call is forwarded on > the way to URI of user C. Then to C the Request URI value that was used > by the forwarding entity (URI of user C) is more relevant URI to decide > how it will render the call to the user then the URI of user B. > > /Hans Erik van Elburg > > On Fri, May 1, 2009 at 3:30 AM, Dean Willis > wrote: > > Hans Erik van Elburg wrote: > > > > > > Dean Willis wrote: > >> > >> On Apr 30, 2009, at 4:38 AM, Hans Erik van Elburg wrote: > >> > >>> Overloading in general is not a good design strategy, why do you > >>> think that trying to mold everything (diversion/history info) into > >>> Request URI is a good idea?? > >> > >> The reason that we're having this conversation is that we have > >> proposals, History-Info being one, for 1) putting our parameters > in to > >> the original request-URI, and 2) recovering that original > request-URI > >> after it has been contact-routed (and otherwise mangled) so that the > >> parameters can be used at the UAS. > >> > >> So the presumption exists that the original request URI is useful to > >> the UAS. SIP did, and now SIPCORE has, a chartered item for making > >> that happen. > >> > >> I'm trying to back up and make sure that we know WHY we're trying to > >> deliver the original request URI to the UAS, and then asking if some > >> other approach that meets the same requirements might actually be > >> easier to do. > >> > > That is fine of course, but the point is that we are not talking > about > > delivering parameters to an application, but about recovering a > complete > > URI that has gone lost on the way. > > but why exactly do we need to recover the URI? What is it that is > special about the URI or is likely to get used in some useful sort of > way downstream? If it isn't the "Request URI-ness" that is important, > maybe we can find some more convenient way to deliver that information. > > > >>> The problem here is that this information has nothing to do with > >>> application invocation, but tells something about how the > signalling > >>> reached the callee (target). And this information is only > relevant to > >>> the callee if that decides that it is. > >> > >> > >> That's a profound philosophical assertion. HTTP, for example, > makes no > >> consideration for "how the signaling reaches the target" in > >> determining how to process a request. The fact that some think SIP > >> should take this into consideration indicates to me that we have a > >> layering problem in our design. > >> > > I don't think SIP and HTTP are comparable at all in this respect. In > > HTTP you directly address the server that you like to get (post, > delete, > > update) information from. In SIP you adress the URI of a user, > that will > > lead you to the home proxy in most cases and which is then > forwarded to > > the UAS by overwriting the Request URI. > > Well, HTTP has proxies too, and SIP were originally intended to be > comparable. > > '> No layering problem, just a flaw in SIP's design that causes usefull > > information to be destroyed for no good reason. We're just trying > to fix > > that, no more no less. > >> From one perspective, this makes the application invocation > implicit; > >> the UAS has to guess what to do based on clues sprinkled throughout > >> the communication and across several layers of the ISO stack. It's > >> much better to have this sort of determination made based on > explicit > >> indicators at a single application layer. > >> > > No. The goal of the target-uri discussion is to have all the relevant > > target-uri information readily available in the SIP request > received by > > the UAS. That is all on the same OSI layer, layer 7. > > > > I disgaree -- the goal is to make the information that was encoded into > the requestURI (and maybe as modified by intermediates, that use case is > open) available to the UAS. > > > -- > dean > > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From attila.sipos@vegastream.com Fri May 1 10:20:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41FC3A684E for ; Fri, 1 May 2009 10:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmyXBarULs4L for ; Fri, 1 May 2009 10:20:15 -0700 (PDT) Received: from cluster-d.mailcontrol.com (cluster-d.mailcontrol.com [85.115.60.190]) by core3.amsl.com (Postfix) with ESMTP id 8CC0C3A693F for ; Fri, 1 May 2009 10:20:14 -0700 (PDT) Received: from rly50d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly50d.srv.mailcontrol.com (MailControl) with ESMTP id n41HLU41019223 for ; Fri, 1 May 2009 18:21:36 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly50d.srv.mailcontrol.com (MailControl) id n41HKl0P012604 for sipcore@ietf.org; Fri, 1 May 2009 18:20:47 +0100 Received: from exsmtp02.nasstar-t1.net (exsmtp02.nasstar-t1.net [89.28.233.152]) by rly50d-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id n41HKhOk012254; Fri, 01 May 2009 18:20:47 +0100 (BST) Received: from EXVS02.nasstar-t1.net ([10.2.10.106]) by exsmtp02.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 18:21:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CA81.3F0E8335" Date: Fri, 1 May 2009 18:18:41 +0100 Message-ID: <680808427CF931459462C3D78CB5EC601CD00F@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] info-03 draft and "session negotiation exchange" Thread-Index: AcnKXo0aoxDwNzsfSCOvyuHJpNMvTAAIlLGS References: <680808427CF931459462C3D78CB5EC6005739F71@EXVS02.nasstar-t1.net> From: "Attila Sipos" To: "Eric Burger" X-OriginalArrivalTime: 01 May 2009 17:21:22.0417 (UTC) FILETIME=[3FA57610:01C9CA81] X-Scanned-By: MailControl A_08_51_00 (www.mailcontrol.com) on 10.68.1.160 Cc: SIPCORE Subject: Re: [sipcore] info-03 draft and "session negotiation exchange" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:20:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CA81.3F0E8335 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>Section 3 is where "negotiation" occurs. I put negotiation in quotes=20 >>because it is an advertising model, not an offer/answer model. That sentence alone, for me, makes it much clearer. I think the confusion comes from: 1. the word negotiation 2. the statement: the target UA MUST NOT send any package P INFO methods until the target UA sees P in the final ACK from the initiating UA. Right now, I'd like the following to be considered: 1. call it a "capability exchange" not a "negotiation" or "renegotiation". 2. have a statement at the end of the first paragraph in section 3 - someth= ing like this: Note well: this is an advertising model - it is NOT a negotiation or off= er/answer model. 3. define what set of messages constitutes an exchange (this I'm still not = clear about - especially where PRACK is involved? can a PRACK response be = considered in the same way as the ACK? ) 4. also can we remove the statement The target UA MUST NOT send any package P INFO methods until the target UA sees P in the final ACK from the initiating UA. There seems contradiction between saying it's an advertising model but m= aking the target UA wait for the ACK. Making the target UA wait implies that it needs to see what the initiato= r says again, which seems more like negotiation behavior. Why not just allow event P anytime after the initiator has declared it = in the Recv-Info of the re-INVITE/INVITE? 5. If we must keep 4, then let's define what should happen if P occurs bef= ore the ACK (which could happen if the package P INFO is sent at the same time as the re-INVITE) Regards, Attila =20 =20 =20 ________________________________ From: Eric Burger [mailto:eburger@standardstrack.com] Sent: Fri 01/05/2009 14:12 To: Attila Sipos Cc: SIPCORE Subject: Re: [sipcore] info-03 draft and "session negotiation exchange" Section 3 is where "negotiation" occurs. I put negotiation in quotes=20 because it is an advertising model, not an offer/answer model. Would changing negotiation language to advertising language reduce=20 confusion, or is it semantic dressing? On Apr 30, 2009, at 2:30 AM, Attila Sipos wrote: > Hi, > > Sorry for questions late in the day but I'm not clear on the > negotiation methods of the info package draft. > > The draft mentions "session negotiation exchange" several times. > > Can someone tell me where this is defined? > > Section 3.1 (UA Behavior) shows INVITE/OK/ACK as an exchange. > > I see from section "5.2. INFO Headers" of the "INFO tables" e-mail > that PRACK and UPDATE are allowed to carry the Recv-Info header. So > what is the "exchange" if say, INVITE and PRACK are involved? > > From section 3.1, it seems that the initial "offer" is in the INVITE > and then "confirmed" in the ACK. So if PRACK is received, can one > "confirm" in a PRACK? > > Also, if Recv-Info is allowed in UPDATE, how does that get=20 > "confirmed"? > Or is it that UPDATE just lists the packages already negotiated? > > Or is it that package renegotiation is only ever done in > INVITE/re-INVITE? > If so, I would like to see some text explicitly stating this. > If not, what renegotiation combinations are there? > > Then there is this... > The limitation on requiring the negotiation to occur within the > context of a session negotiation exchange means that if the > initiating UA issues a re-INVITE (after the above ACK) with the > following. > > INVITE ... > ... > Recv-Info: P, R, T > ... > > The target UA MUST NOT send any package P INFO methods until the > target UA sees P in the final ACK from the initiating UA. > > > So, let's say P was being sent by the target. Then when the > re-INVITE arrives, P has to be stopped (or queued), until P is > seen again in the ACK. > > So what happens if there is a re-INVITE/INFO(package P) crossover? > I think we need to say that if the initiating UA receives the INFO > for package P, it should either: > 1. still process it as normal > or > 2. issue a 4xx response (something like 491 Request Pending) > so that the package P event can be re-attempted once the ACK > has been received. > > Regards, > > Attila > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore ------_=_NextPart_001_01C9CA81.3F0E8335 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] info-03 draft and "session negot= iation exchange"
>>Section = 3 is where "negotiation" occurs.  I put negotiation in quotes
>= >because it is an advertising model, not an offer/answer model.
That sentence al= one, for me, makes it much clearer.
I think the conf= usion comes from:
1. the word negotiation
2. the statement:
 =      the target UA MUST NOT send any package P INFO met= hods until the
      target UA sees P in the fi= nal ACK from the initiating UA.

Right now, I'd like the following to be considered:
1= . call it a "capability exchange" not a "negotiation" or "renegotiation".2. have a statement at the end of the first paragraph in section 3 - some= thing like this:
   Note well: this is an advertising model - = it is NOT a negotiation or offer/answer model.
3. define what set of mes= sages constitutes an exchange (this I'm still not clear about - especially = where PRACK is involved?  can a PRACK response be considered in the sa= me way as the ACK? )
4. also can we remove the statement
 &= nbsp;    The target UA MUST NOT send any package P INFO meth= ods until the
      target UA sees P in the fin= al ACK from the initiating UA.
   There seems contradiction be= tween saying it's an advertising model but making the target UA wait for th= e ACK.
   Making the target UA wait implies that it needs to s= ee what the initiator says again, which seems more like negotiation behavio= r.
    Why not just allow event P anytime after the initi= ator has declared it in the Recv-Info of the re-INVITE/INVITE?
5.  = If we must keep 4, then let's define what should happen if P occurs before = the ACK (which could happen
    if the package P INFO is = sent at the same time as the re-INVITE)

Regards,
Attila
 
 
 

From: Eric Burger [mailto:eburger@stand= ardstrack.com]
Sent: Fri 01/05/2009 14:12
To: Attila Si= pos
Cc: SIPCORE
Subject: Re: [sipcore] info-03 draft an= d "session negotiation exchange"

Section 3 is where "negotiation" occurs.  I put nego= tiation in quotes 
because it is an advertising model, not an offer= /answer model.

Would changing negotiation language to advertising la= nguage reduce 
confusion, or is it semantic dressing?

On Apr= 30, 2009, at 2:30 AM, Attila Sipos wrote:

> Hi,
>
> = Sorry for questions late in the day but I'm not clear on the
> negoti= ation methods of the info package draft.
>
> The draft mentions= "session negotiation exchange" several times.
>
> Can someone = tell me where this is defined?
>
> Section 3.1 (UA Behavior) sh= ows INVITE/OK/ACK as an exchange.
>
> I see from section "5.2.&= nbsp; INFO Headers" of the "INFO tables" e-mail
> that PRACK and UPDA= TE are allowed to carry the Recv-Info header. So
> what is the "excha= nge" if say, INVITE and PRACK are involved?
>
> From section 3.= 1, it seems that the initial "offer" is in the INVITE
> and then "con= firmed" in the ACK. So if PRACK is received, can one
> "confirm" in a= PRACK?
>
> Also, if Recv-Info is allowed in UPDATE, how does t= hat get 
> "confirmed"?
> Or is it that UPDATE just lists = the packages already negotiated?
>
> Or is it that package rene= gotiation is only ever done in
> INVITE/re-INVITE?
> If so, I w= ould like to see some text explicitly stating this.
> If not, what re= negotiation combinations are there?
>
> Then there is this...>   The limitation on requiring the negotiation to occur wit= hin the
>   context of a session negotiation exchange means= that if the
>   initiating UA issues a re-INVITE (after th= e above ACK) with the
>   following.
>
> &= nbsp; INVITE ...
>   ...
>   Recv-Info: P, = R, T
>   ...
>
>   The target UA MUST= NOT send any package P INFO methods until the
>   target U= A sees P in the final ACK from the initiating UA.
>
>
> S= o, let's say P was being sent by the target.   Then when the
&= gt; re-INVITE arrives, P has to be stopped (or queued), until P is
> = seen again in the ACK.
>
> So what happens if there is a re-INV= ITE/INFO(package P) crossover?
> I think we need to say that if the i= nitiating UA receives the INFO
> for package P, it should either:
= > 1. still process it as normal
> or
> 2. issue a 4xx respon= se (something like 491 Request Pending)
>   so that the pac= kage P event can be re-attempted once the ACK
>   has been = received.
>
> Regards,
>
> Attila
>
>>
>
> _______________________________________________
&= gt; sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listi= nfo/sipcore



.

= ------_=_NextPart_001_01C9CA81.3F0E8335-- From pkyzivat@cisco.com Fri May 1 11:37:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10BF428C245 for ; Fri, 1 May 2009 11:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6ZBqxjjBOB8 for ; Fri, 1 May 2009 11:37:20 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 13D5B3A7097 for ; Fri, 1 May 2009 11:35:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="296684402" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 May 2009 18:37:23 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n41IbNOM001874; Fri, 1 May 2009 11:37:23 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n41IbKoK000658; Fri, 1 May 2009 18:37:22 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 14:37:20 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 14:37:20 -0400 Message-ID: <49FB415F.90905@cisco.com> Date: Fri, 01 May 2009 14:37:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> <9ae56b1e0905010808s50a236dcge61b9f8250dfec9@mail.gmail.com> <49FB1CC2.5060802@joelhalpern.com> In-Reply-To: <49FB1CC2.5060802@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2009 18:37:20.0404 (UTC) FILETIME=[DC6B1540:01C9CA8B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1708; t=1241203043; x=1242067043; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Long=20reply=20to=3A=20Targ et=20URI=20and=20History=20Info=20bis |Sender:=20; bh=u50JOBir7bDgi9DnmFSurHhfHq0hAPccC5waAToKP2k=; b=IhYWlkfcuIyQw5bAFdbPDQxrCbkzSFsyJvD13zik5D2qqhlryvVxrqAU/5 IJ8lRSLdSnfzxGXQSf5st0FSaQjHRQIe16G/8NYsKEN493nAD6NrhrjWHQ0n +3xxB+jR1P; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:37:21 -0000 Joel M. Halpern wrote: [snip] > And depending upon how everything was understood, and why it was being > redirected, the destination of the redirect may or may not care about > the original URI (may even care about the user part of the original URI) > in full, in order to decide what to do (the voicemail examples.) I suspect that the voicemail example is a subtext to many of the arguments on this subject. And that troubles me. The arguments I think I hear for and about this are: - Alice calls Bob - Bob forwards to Carol - its forwarded again to Voicemail - the desire is for it to be Bob's voicemail, not Carol's. - And so *the* voicemail server needs to figure out whether to use Bob's voicemailbox or Carol's. The trouble with this is that it presumes that Bob and Carol share a common VM server, or at least VM servers that collude with one another. While this is frequently the case, IMO it is a terrible assumption upon which to base a mechanism. For instance, Bob may have been called at work, which has its own VM system, and Carol may be Bob's wife with a VM system provided by her cellphone SP. In that case, even if Carol's VM server is able to discern that the call was intended for Bob, it won't have access to Bob's voicemailbox. Solving this problem is really a matter of arranging when forwarding to Carol that the call will fail rather than go to Carol's VM. Then Bob's proxy will have the opportunity to forward the call to Bob's VM server. And in that case there won't be any complex issues about what mailbox it is. So, what *other* problems are there where knowing the original R-URI is important? Thanks, Paul From dean.willis@softarmor.com Fri May 1 15:39:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151533A6D80 for ; Fri, 1 May 2009 15:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg5xAByKq1xx for ; Fri, 1 May 2009 15:39:36 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 274623A6803 for ; Fri, 1 May 2009 15:39:36 -0700 (PDT) Received: from [192.168.2.103] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n41MevRo003323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 May 2009 17:40:58 -0500 Message-Id: <7AC11AB9-5098-4536-B121-1F825E525D45@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <49FB415F.90905@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 17:40:51 -0500 References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> <9ae56b1e0905010808s50a236dcge61b9f8250dfec9@mail.gmail.com> <49FB1CC2.5060802@joelhalpern.com> <49FB415F.90905@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 22:39:37 -0000 On May 1, 2009, at 1:37 PM, Paul Kyzivat wrote: > > I suspect that the voicemail example is a subtext to many of the > arguments on this subject. > > And that troubles me. The arguments I think I hear for and about > this are: > - Alice calls Bob > - Bob forwards to Carol > - its forwarded again to Voicemail > - the desire is for it to be Bob's voicemail, not Carol's. > - And so *the* voicemail server needs to figure out whether > to use Bob's voicemailbox or Carol's. > > The trouble with this is that it presumes that Bob and Carol share a > common VM server, or at least VM servers that collude with one > another. While this is frequently the case, IMO it is a terrible > assumption upon which to base a mechanism. For instance, Bob may > have been called at work, which has its own VM system, and Carol may > be Bob's wife with a VM system provided by her cellphone SP. In that > case, even if Carol's VM server is able to discern that the call was > intended for Bob, it won't have access to Bob's voicemailbox. That's just broken. The easiest solution is for Carol's node to return a "no answer" to Bob's forwarding server, which then needs to route the call to Bob's VM. The question is "How does Carol's node know whether to send a no- answer instead of sending the call to Carol's VM?" The only answer that works for me is that Bob's forwarding server needs to tag the request in some way that gives Carol's node this information. I suspect that caller-preferences (sip.automata)=FALSE) gives us this capability, and that the solution here is proper configuration of Bob's forwarding server (and support for caller- preferences in Carol's node, which Bob's server can test with Require:). Others might argue that an extension to Diversion is required that would allow detection of this state. I'd argue that this is bogus; Carol's node should not have to guess what is wanted based on what has already happened (an implicit preference). Instead, it should be told explicitly what outcome is desired (an explicit preference). Another model is to add yet another extension that says "If you can't answer, please route this call to this alternate URI". Bob's forwarding server would then add this extension, attaching the URI for Bob's VM. Carol's node would then dispatch the request appropriately. This approach just seems a little fudgy to me, with lots of undesirable security properties. -- Dean From pkyzivat@cisco.com Fri May 1 16:24:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC853A69FE for ; Fri, 1 May 2009 16:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.133 X-Spam-Level: X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwv0Y-et045f for ; Fri, 1 May 2009 16:24:02 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A4FCB3A68B8 for ; Fri, 1 May 2009 16:24:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="43146342" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 May 2009 23:25:26 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n41NPQIS005085; Fri, 1 May 2009 19:25:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n41NPQRv003898; Fri, 1 May 2009 23:25:26 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 19:25:26 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 19:25:25 -0400 Message-ID: <49FB84E4.8070507@cisco.com> Date: Fri, 01 May 2009 19:25:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> <9ae56b1e0905010808s50a236dcge61b9f8250dfec9@mail.gmail.com> <49FB1CC2.5060802@joelhalpern.com> <49FB415F.90905@cisco.com> <7AC11AB9-5098-4536-B121-1F825E525D45@softarmor.com> In-Reply-To: <7AC11AB9-5098-4536-B121-1F825E525D45@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2009 23:25:25.0676 (UTC) FILETIME=[1B3E46C0:01C9CAB4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3016; t=1241220326; x=1242084326; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Long=20reply=20to=3A=20Targ et=20URI=20and=20History=20Info=20bis |Sender:=20 |To:=20Dean=20Willis=20; bh=VWgZjoR1TqYmSfNDjQTjcLWTFwmugBzXhZn2ddah4bY=; b=ANfWz1qAnbQwWpCIRJd9TXF7SLuniQgiY7ZjkLXIXk12c7i9CLDCKhJee4 XyWKf9EE9sJ5xQESJB4/EMAgM6n5hFYqkddsFnB7I6iz4KKRbnm0aTAj59B5 29qEEvaIBC; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 23:24:04 -0000 Yes, I did have in mind that callerprefs can cause the right thing to happen if inserted properly and honored. (Big ifs, but alternatives that do the right thing are also big ifs.) I would like to know if people have this case in mind when worrying about Diversion/H-I/Target URI issues. Thanks, Paul P.S. Dean - you cut off my text that said pretty much what you added. Dean Willis wrote: > > On May 1, 2009, at 1:37 PM, Paul Kyzivat wrote: > >> >> I suspect that the voicemail example is a subtext to many of the >> arguments on this subject. >> >> And that troubles me. The arguments I think I hear for and about this >> are: >> - Alice calls Bob >> - Bob forwards to Carol >> - its forwarded again to Voicemail >> - the desire is for it to be Bob's voicemail, not Carol's. >> - And so *the* voicemail server needs to figure out whether >> to use Bob's voicemailbox or Carol's. >> >> The trouble with this is that it presumes that Bob and Carol share a >> common VM server, or at least VM servers that collude with one >> another. While this is frequently the case, IMO it is a terrible >> assumption upon which to base a mechanism. For instance, Bob may have >> been called at work, which has its own VM system, and Carol may be >> Bob's wife with a VM system provided by her cellphone SP. In that >> case, even if Carol's VM server is able to discern that the call was >> intended for Bob, it won't have access to Bob's voicemailbox. > > That's just broken. The easiest solution is for Carol's node to return a > "no answer" to Bob's forwarding server, which then needs to route the > call to Bob's VM. > > The question is "How does Carol's node know whether to send a no-answer > instead of sending the call to Carol's VM?" > > The only answer that works for me is that Bob's forwarding server needs > to tag the request in some way that gives Carol's node this information. > I suspect that caller-preferences (sip.automata)=FALSE) gives us this > capability, and that the solution here is proper configuration of Bob's > forwarding server (and support for caller-preferences in Carol's node, > which Bob's server can test with Require:). > > Others might argue that an extension to Diversion is required that would > allow detection of this state. I'd argue that this is bogus; Carol's > node should not have to guess what is wanted based on what has already > happened (an implicit preference). Instead, it should be told explicitly > what outcome is desired (an explicit preference). > > Another model is to add yet another extension that says "If you can't > answer, please route this call to this alternate URI". Bob's forwarding > server would then add this extension, attaching the URI for Bob's VM. > Carol's node would then dispatch the request appropriately. This > approach just seems a little fudgy to me, with lots of undesirable > security properties. > > -- > Dean > > > > From christer.holmberg@ericsson.com Sun May 3 11:00:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8F83A6F99 for ; Sun, 3 May 2009 11:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.084 X-Spam-Level: X-Spam-Status: No, score=-5.084 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_05=-1.11, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nl3Zl299bLqf for ; Sun, 3 May 2009 11:00:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BA3B73A6AF6 for ; Sun, 3 May 2009 10:59:59 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-1e-49fddbf3d874 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 07.14.19078.3FBDDF94; Sun, 3 May 2009 20:01:23 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 May 2009 20:00:28 +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: Sun, 3 May 2009 20:00:28 +0200 Message-ID: In-Reply-To: <49FA50CD.1080406@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Long reply to: Target URI and History Info bis Thread-Index: AcnJ/HyfnVMxhUsOSO2+v4oIAfZjvACGuIbQ References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com><06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com><49F9718E.4070707@gmail.com><9A564A10-3F22-471A-832B-28117412AD93@softarmor.com><49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , "Hans Erik van Elburg" X-OriginalArrivalTime: 03 May 2009 18:00:28.0804 (UTC) FILETIME=[0B073440:01C9CC19] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 18:00:08 -0000 Hi, I think the why-is-this-needed questions should have been asked when we decided to start working on this in the first place. And, again, the different drafts that have been produced on this topic DO describe different use-cases. Regarding the solution, again, we had a long discussion about it, argued about different alternatives, and finally decided to go for a H-I based solution. I am sure there are other ways to do this than using H-I, but everybody had his/her chance to participate in the beauty contest on which solution to choose, so at this point I don't think we should revise our decission - unless it can be shown that the H-I based solution doesn't work.=20 Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, May 01, 2009 4:31 AM To: Hans Erik van Elburg Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis Hans Erik van Elburg wrote: >=20 >=20 > Dean Willis wrote: >> >> On Apr 30, 2009, at 4:38 AM, Hans Erik van Elburg wrote: >> >>> Overloading in general is not a good design strategy, why do you=20 >>> think that trying to mold everything (diversion/history info) into=20 >>> Request URI is a good idea?? >> >> The reason that we're having this conversation is that we have=20 >> proposals, History-Info being one, for 1) putting our parameters in=20 >> to the original request-URI, and 2) recovering that original=20 >> request-URI after it has been contact-routed (and otherwise mangled)=20 >> so that the parameters can be used at the UAS. >> >> So the presumption exists that the original request URI is useful to=20 >> the UAS. SIP did, and now SIPCORE has, a chartered item for making=20 >> that happen. >> >> I'm trying to back up and make sure that we know WHY we're trying to=20 >> deliver the original request URI to the UAS, and then asking if some=20 >> other approach that meets the same requirements might actually be=20 >> easier to do. >> > That is fine of course, but the point is that we are not talking about > delivering parameters to an application, but about recovering a=20 > complete URI that has gone lost on the way. but why exactly do we need to recover the URI? What is it that is special about the URI or is likely to get used in some useful sort of way downstream? If it isn't the "Request URI-ness" that is important, maybe we can find some more convenient way to deliver that information. >>> The problem here is that this information has nothing to do with=20 >>> application invocation, but tells something about how the signalling >>> reached the callee (target). And this information is only relevant=20 >>> to the callee if that decides that it is. >> >> >> That's a profound philosophical assertion. HTTP, for example, makes=20 >> no consideration for "how the signaling reaches the target" in=20 >> determining how to process a request. The fact that some think SIP=20 >> should take this into consideration indicates to me that we have a=20 >> layering problem in our design. >> > I don't think SIP and HTTP are comparable at all in this respect. In=20 > HTTP you directly address the server that you like to get (post,=20 > delete, > update) information from. In SIP you adress the URI of a user, that=20 > will lead you to the home proxy in most cases and which is then=20 > forwarded to the UAS by overwriting the Request URI. Well, HTTP has proxies too, and SIP were originally intended to be comparable. '> No layering problem, just a flaw in SIP's design that causes usefull > information to be destroyed for no good reason. We're just trying to=20 > fix that, no more no less. >> From one perspective, this makes the application invocation implicit; >> the UAS has to guess what to do based on clues sprinkled throughout=20 >> the communication and across several layers of the ISO stack. It's=20 >> much better to have this sort of determination made based on explicit >> indicators at a single application layer. >> > No. The goal of the target-uri discussion is to have all the relevant=20 > target-uri information readily available in the SIP request received=20 > by the UAS. That is all on the same OSI layer, layer 7. >=20 I disgaree -- the goal is to make the information that was encoded into the requestURI (and maybe as modified by intermediates, that use case is open) available to the UAS. -- dean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Sun May 3 11:24:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119403A70E6 for ; Sun, 3 May 2009 11:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEMmVz-MxWyF for ; Sun, 3 May 2009 11:24:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6C8A728C25C for ; Sun, 3 May 2009 11:24:32 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-a3-49fde1b4c7d2 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id CC.84.19078.4B1EDF94; Sun, 3 May 2009 20:25:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 May 2009 20:25: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 Date: Sun, 3 May 2009 20:25:05 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnJum/b2hRk+CDkRk2wxEFtMy23fQCYSVLw References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> From: "Christer Holmberg" To: "Dean Willis" , "Hans Erik van Elburg" X-OriginalArrivalTime: 03 May 2009 18:25:06.0666 (UTC) FILETIME=[7BE70CA0:01C9CC1C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 18:24:38 -0000 Hi,=20 >>The option tag is a means of 1) discovering whether or not the far-=20 >>end supports a specific extension and of 2) declaring the criticality=20 >>of understanding that extension relative to satisfying a request and=20 >>3) informing the UAC of what extensions were applied to the request=20 >>in order to generate the response. This is purely a function of=20 >>capability negotiation, not one of invocation. >> >>The extension itself (typically, an extension header field, although=20 >>there are other types of extensions) is what causes the extension to=20 >>be invoked. >Depends a bit how you define extension, but I would argue that if I=20 >require an extension to be supported on a transaction/dialog by the=20 >UAS and the UAS accepts the request that this means that for this call=20 >the UAS behaves as it should according to the extensions=20 >specification. > >Saying that an extensions invokes itself is meaningless to me. > >A UAS may choose to only invoke the extension behaviour if it finds=20 >that the extension is required. That comes close to saying that the=20 >require:extension invokes the behaviour in the UAS, but it is not at=20 >all the same. > > >The Require doesn't control whether the UAS invokes the extension. The UAS may invoke the extension on its own recognizance. Most likely, it chooses to do so based on 1) the presence of a Supported=20 >indicator for the extension in a request as evidence that the UAC supports the extension or the presence of an extension header in the request that also indicates support in the UAC and 2) support for=20 >that extension in the UAS. Other extensions may not require support in the UAC, so may be enacted by this UAS purely on local policy. 100rel does not carry any extension headers in the request, nor does RFC3262 say that the UAC must insert Supported in addition to Require. But, RFC3262 DOES say: "The UAS MUST send any non-100 provisional response reliably if the initial request contained a Require header field with the option tag 100rel." So, in my opinion Require:100rel means: 1. The UAC supports 100rel (no Suppored needed) 2. The UAS MUST use the extension (if sending non-100 provisional responses). I have nothing against saying that the definition of each option-tag should specify how it is used, and what Require really means as far as the UAS is concerned, but I don't think the generic definition of Supported and Require that you are proposing fits all cases. Regards, Christer From mdolly@att.com Sun May 3 12:42:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC40628C26D for ; Sun, 3 May 2009 12:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YNnAqqOC6K4 for ; Sun, 3 May 2009 12:42:20 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id E2B3628C287 for ; Sun, 3 May 2009 12:41:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-8.tower-161.messagelabs.com!1241379787!19600602!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 23003 invoked from network); 3 May 2009 19:43:07 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-8.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2009 19:43:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n43Jh4km020810; Sun, 3 May 2009 15:43:06 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n43JgxDQ020648; Sun, 3 May 2009 15:42:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 3 May 2009 15:42:59 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F9@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Long reply to: Target URI and History Info bis Thread-Index: AcnJ/HyfnVMxhUsOSO2+v4oIAfZjvACGuIbQAAP/mzA= From: "DOLLY, MARTIN C, ATTLABS" To: , , Cc: sipcore@ietf.org Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 19:42:27 -0000 SGVsbG8NCg0KSSBhZ3JlZSB3aXRoIENocmlzdGVyLCB0aGVyZSB3YXMgY2xlYXIgY29uc2Vuc3Vz IG9uIHRoZSBwYXRoIGZvcndhcmQgZm9yIHRoaXMgaXNzdWUsIG5vIG9wcG9zaXRpb24uDQoNCk1h cnRpbg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBzaXBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmcgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4NClRvOiBEZWFuIFdpbGxpcyA8 ZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbT47IEhhbnMgRXJpayB2YW4gRWxidXJnIDxpZXRmLmhh bnNlcmlrQGdtYWlsLmNvbT4NCkNjOiBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KU2VudDog U3VuIE1heSAwMyAxNDowMDoyOCAyMDA5DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIExvbmcgcmVw bHkgdG86ICBUYXJnZXQgVVJJIGFuZCBIaXN0b3J5IEluZm8gYmlzDQoNCg0KSGksDQoNCkkgdGhp bmsgdGhlIHdoeS1pcy10aGlzLW5lZWRlZCBxdWVzdGlvbnMgc2hvdWxkIGhhdmUgYmVlbiBhc2tl ZCB3aGVuIHdlDQpkZWNpZGVkIHRvIHN0YXJ0IHdvcmtpbmcgb24gdGhpcyBpbiB0aGUgZmlyc3Qg cGxhY2UuIEFuZCwgYWdhaW4sIHRoZQ0KZGlmZmVyZW50IGRyYWZ0cyB0aGF0IGhhdmUgYmVlbiBw cm9kdWNlZCBvbiB0aGlzIHRvcGljIERPIGRlc2NyaWJlDQpkaWZmZXJlbnQgdXNlLWNhc2VzLg0K DQpSZWdhcmRpbmcgdGhlIHNvbHV0aW9uLCBhZ2Fpbiwgd2UgaGFkIGEgbG9uZyBkaXNjdXNzaW9u IGFib3V0IGl0LCBhcmd1ZWQNCmFib3V0IGRpZmZlcmVudCBhbHRlcm5hdGl2ZXMsIGFuZCBmaW5h bGx5IGRlY2lkZWQgdG8gZ28gZm9yIGEgSC1JIGJhc2VkDQpzb2x1dGlvbi4NCg0KSSBhbSBzdXJl IHRoZXJlIGFyZSBvdGhlciB3YXlzIHRvIGRvIHRoaXMgdGhhbiB1c2luZyBILUksIGJ1dCBldmVy eWJvZHkNCmhhZCBoaXMvaGVyIGNoYW5jZSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgYmVhdXR5IGNv bnRlc3Qgb24gd2hpY2gNCnNvbHV0aW9uIHRvIGNob29zZSwgc28gYXQgdGhpcyBwb2ludCBJIGRv bid0IHRoaW5rIHdlIHNob3VsZCByZXZpc2Ugb3VyDQpkZWNpc3Npb24gLSB1bmxlc3MgaXQgY2Fu IGJlIHNob3duIHRoYXQgdGhlIEgtSSBiYXNlZCBzb2x1dGlvbiBkb2Vzbid0DQp3b3JrLiANCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGll dGYub3JnXSBPbg0KQmVoYWxmIE9mIERlYW4gV2lsbGlzDQpTZW50OiBGcmlkYXksIE1heSAwMSwg MjAwOSA0OjMxIEFNDQpUbzogSGFucyBFcmlrIHZhbiBFbGJ1cmcNCkNjOiBTSVBDT1JFDQpTdWJq ZWN0OiBSZTogW3NpcGNvcmVdIExvbmcgcmVwbHkgdG86IFRhcmdldCBVUkkgYW5kIEhpc3Rvcnkg SW5mbyBiaXMNCg0KSGFucyBFcmlrIHZhbiBFbGJ1cmcgd3JvdGU6DQo+IA0KPiANCj4gRGVhbiBX aWxsaXMgd3JvdGU6DQo+Pg0KPj4gT24gQXByIDMwLCAyMDA5LCBhdCA0OjM4IEFNLCBIYW5zIEVy aWsgdmFuIEVsYnVyZyB3cm90ZToNCj4+DQo+Pj4gT3ZlcmxvYWRpbmcgaW4gZ2VuZXJhbCBpcyBu b3QgYSBnb29kIGRlc2lnbiBzdHJhdGVneSwgd2h5IGRvIHlvdSANCj4+PiB0aGluayB0aGF0IHRy eWluZyB0byBtb2xkIGV2ZXJ5dGhpbmcgKGRpdmVyc2lvbi9oaXN0b3J5IGluZm8pIGludG8gDQo+ Pj4gUmVxdWVzdCBVUkkgaXMgYSBnb29kIGlkZWE/Pw0KPj4NCj4+IFRoZSByZWFzb24gdGhhdCB3 ZSdyZSBoYXZpbmcgdGhpcyBjb252ZXJzYXRpb24gaXMgdGhhdCB3ZSBoYXZlIA0KPj4gcHJvcG9z YWxzLCBIaXN0b3J5LUluZm8gYmVpbmcgb25lLCBmb3IgMSkgcHV0dGluZyBvdXIgcGFyYW1ldGVy cyBpbiANCj4+IHRvIHRoZSBvcmlnaW5hbCByZXF1ZXN0LVVSSSwgYW5kIDIpIHJlY292ZXJpbmcg dGhhdCBvcmlnaW5hbCANCj4+IHJlcXVlc3QtVVJJIGFmdGVyIGl0IGhhcyBiZWVuIGNvbnRhY3Qt cm91dGVkIChhbmQgb3RoZXJ3aXNlIG1hbmdsZWQpIA0KPj4gc28gdGhhdCB0aGUgcGFyYW1ldGVy cyBjYW4gYmUgdXNlZCBhdCB0aGUgVUFTLg0KPj4NCj4+IFNvIHRoZSBwcmVzdW1wdGlvbiBleGlz dHMgdGhhdCB0aGUgb3JpZ2luYWwgcmVxdWVzdCBVUkkgaXMgdXNlZnVsIHRvIA0KPj4gdGhlIFVB Uy4gU0lQIGRpZCwgYW5kIG5vdyBTSVBDT1JFIGhhcywgYSBjaGFydGVyZWQgaXRlbSBmb3IgbWFr aW5nIA0KPj4gdGhhdCBoYXBwZW4uDQo+Pg0KPj4gSSdtIHRyeWluZyB0byBiYWNrIHVwIGFuZCBt YWtlIHN1cmUgdGhhdCB3ZSBrbm93IFdIWSB3ZSdyZSB0cnlpbmcgdG8gDQo+PiBkZWxpdmVyIHRo ZSBvcmlnaW5hbCByZXF1ZXN0IFVSSSB0byB0aGUgVUFTLCBhbmQgdGhlbiBhc2tpbmcgaWYgc29t ZSANCj4+IG90aGVyIGFwcHJvYWNoIHRoYXQgbWVldHMgdGhlIHNhbWUgcmVxdWlyZW1lbnRzIG1p Z2h0IGFjdHVhbGx5IGJlIA0KPj4gZWFzaWVyIHRvIGRvLg0KPj4NCj4gVGhhdCBpcyBmaW5lIG9m IGNvdXJzZSwgYnV0IHRoZSBwb2ludCBpcyB0aGF0IHdlIGFyZSBub3QgdGFsa2luZyBhYm91dA0K DQo+IGRlbGl2ZXJpbmcgcGFyYW1ldGVycyB0byBhbiBhcHBsaWNhdGlvbiwgYnV0IGFib3V0IHJl Y292ZXJpbmcgYSANCj4gY29tcGxldGUgVVJJIHRoYXQgaGFzIGdvbmUgbG9zdCBvbiB0aGUgd2F5 Lg0KDQpidXQgd2h5IGV4YWN0bHkgZG8gd2UgbmVlZCB0byByZWNvdmVyIHRoZSBVUkk/IFdoYXQg aXMgaXQgdGhhdCBpcw0Kc3BlY2lhbCBhYm91dCB0aGUgVVJJIG9yIGlzIGxpa2VseSB0byBnZXQg dXNlZCBpbiBzb21lIHVzZWZ1bCBzb3J0IG9mDQp3YXkgZG93bnN0cmVhbT8gSWYgaXQgaXNuJ3Qg dGhlICJSZXF1ZXN0IFVSSS1uZXNzIiB0aGF0IGlzIGltcG9ydGFudCwNCm1heWJlIHdlIGNhbiBm aW5kIHNvbWUgbW9yZSBjb252ZW5pZW50IHdheSB0byBkZWxpdmVyIHRoYXQgaW5mb3JtYXRpb24u DQoNCg0KPj4+IFRoZSBwcm9ibGVtIGhlcmUgaXMgdGhhdCB0aGlzIGluZm9ybWF0aW9uIGhhcyBu b3RoaW5nIHRvIGRvIHdpdGggDQo+Pj4gYXBwbGljYXRpb24gaW52b2NhdGlvbiwgYnV0IHRlbGxz IHNvbWV0aGluZyBhYm91dCBob3cgdGhlIHNpZ25hbGxpbmcNCg0KPj4+IHJlYWNoZWQgdGhlIGNh bGxlZSAodGFyZ2V0KS4gQW5kIHRoaXMgaW5mb3JtYXRpb24gaXMgb25seSByZWxldmFudCANCj4+ PiB0byB0aGUgY2FsbGVlIGlmIHRoYXQgZGVjaWRlcyB0aGF0IGl0IGlzLg0KPj4NCj4+DQo+PiBU aGF0J3MgYSBwcm9mb3VuZCBwaGlsb3NvcGhpY2FsIGFzc2VydGlvbi4gSFRUUCwgZm9yIGV4YW1w bGUsIG1ha2VzIA0KPj4gbm8gY29uc2lkZXJhdGlvbiBmb3IgImhvdyB0aGUgc2lnbmFsaW5nIHJl YWNoZXMgdGhlIHRhcmdldCIgaW4gDQo+PiBkZXRlcm1pbmluZyBob3cgdG8gcHJvY2VzcyBhIHJl cXVlc3QuIFRoZSBmYWN0IHRoYXQgc29tZSB0aGluayBTSVAgDQo+PiBzaG91bGQgdGFrZSB0aGlz IGludG8gY29uc2lkZXJhdGlvbiBpbmRpY2F0ZXMgdG8gbWUgdGhhdCB3ZSBoYXZlIGEgDQo+PiBs YXllcmluZyBwcm9ibGVtIGluIG91ciBkZXNpZ24uDQo+Pg0KPiBJIGRvbid0IHRoaW5rIFNJUCBh bmQgSFRUUCBhcmUgY29tcGFyYWJsZSBhdCBhbGwgaW4gdGhpcyByZXNwZWN0LiBJbiANCj4gSFRU UCB5b3UgZGlyZWN0bHkgYWRkcmVzcyB0aGUgc2VydmVyIHRoYXQgeW91IGxpa2UgdG8gZ2V0IChw b3N0LCANCj4gZGVsZXRlLA0KPiB1cGRhdGUpIGluZm9ybWF0aW9uIGZyb20uIEluIFNJUCB5b3Ug YWRyZXNzIHRoZSBVUkkgb2YgYSB1c2VyLCB0aGF0IA0KPiB3aWxsIGxlYWQgeW91IHRvIHRoZSBo b21lIHByb3h5IGluIG1vc3QgY2FzZXMgYW5kIHdoaWNoIGlzIHRoZW4gDQo+IGZvcndhcmRlZCB0 byB0aGUgVUFTIGJ5IG92ZXJ3cml0aW5nIHRoZSBSZXF1ZXN0IFVSSS4NCg0KV2VsbCwgSFRUUCBo YXMgcHJveGllcyB0b28sIGFuZCBTSVAgd2VyZSBvcmlnaW5hbGx5IGludGVuZGVkIHRvIGJlDQpj b21wYXJhYmxlLg0KDQonPiBObyBsYXllcmluZyBwcm9ibGVtLCBqdXN0IGEgZmxhdyBpbiBTSVAn cyBkZXNpZ24gdGhhdCBjYXVzZXMgdXNlZnVsbA0KPiBpbmZvcm1hdGlvbiB0byBiZSBkZXN0cm95 ZWQgZm9yIG5vIGdvb2QgcmVhc29uLiBXZSdyZSBqdXN0IHRyeWluZyB0byANCj4gZml4IHRoYXQs IG5vIG1vcmUgbm8gbGVzcy4NCj4+IEZyb20gb25lIHBlcnNwZWN0aXZlLCB0aGlzIG1ha2VzIHRo ZSBhcHBsaWNhdGlvbiBpbnZvY2F0aW9uIGltcGxpY2l0Ow0KDQo+PiB0aGUgVUFTIGhhcyB0byBn dWVzcyB3aGF0IHRvIGRvIGJhc2VkIG9uIGNsdWVzIHNwcmlua2xlZCB0aHJvdWdob3V0IA0KPj4g dGhlIGNvbW11bmljYXRpb24gYW5kIGFjcm9zcyBzZXZlcmFsIGxheWVycyBvZiB0aGUgSVNPIHN0 YWNrLiBJdCdzIA0KPj4gbXVjaCBiZXR0ZXIgdG8gaGF2ZSB0aGlzIHNvcnQgb2YgZGV0ZXJtaW5h dGlvbiBtYWRlIGJhc2VkIG9uIGV4cGxpY2l0DQoNCj4+IGluZGljYXRvcnMgYXQgYSBzaW5nbGUg YXBwbGljYXRpb24gbGF5ZXIuDQo+Pg0KPiBOby4gVGhlIGdvYWwgb2YgdGhlIHRhcmdldC11cmkg ZGlzY3Vzc2lvbiBpcyB0byBoYXZlIGFsbCB0aGUgcmVsZXZhbnQgDQo+IHRhcmdldC11cmkgaW5m b3JtYXRpb24gcmVhZGlseSBhdmFpbGFibGUgaW4gdGhlIFNJUCByZXF1ZXN0IHJlY2VpdmVkIA0K PiBieSB0aGUgVUFTLiBUaGF0IGlzIGFsbCBvbiB0aGUgc2FtZSBPU0kgbGF5ZXIsIGxheWVyIDcu DQo+IA0KDQpJIGRpc2dhcmVlIC0tIHRoZSBnb2FsIGlzIHRvIG1ha2UgdGhlIGluZm9ybWF0aW9u IHRoYXQgd2FzIGVuY29kZWQgaW50bw0KdGhlIHJlcXVlc3RVUkkgKGFuZCBtYXliZSBhcyBtb2Rp ZmllZCBieSBpbnRlcm1lZGlhdGVzLCB0aGF0IHVzZSBjYXNlIGlzDQpvcGVuKSBhdmFpbGFibGUg dG8gdGhlIFVBUy4NCg0KDQotLQ0KZGVhbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcg bGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXBjb3JlDQo= From dean.willis@softarmor.com Sun May 3 22:53:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4278F3A69D8 for ; Sun, 3 May 2009 22:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql1XtwOhKzX6 for ; Sun, 3 May 2009 22:53:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6ADE83A69A2 for ; Sun, 3 May 2009 22:53:17 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n445sbWe019640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 00:54:38 -0500 Message-Id: <9E895F3D-EE68-49E9-B262-034CFE035C15@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 00:54:31 -0500 References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com><06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com><49F9718E.4070707@gmail.com><9A564A10-3F22-471A-832B-28117412AD93@softarmor.com><49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 05:53:30 -0000 On May 3, 2009, at 1:00 PM, Christer Holmberg wrote: > > Hi, > > I think the why-is-this-needed questions should have been asked when > we > decided to start working on this in the first place. And, again, the > different drafts that have been produced on this topic DO describe > different use-cases. I asked it then. I asked them as part of the process that lead to us chartering a deliverable of solving the problem. The reason I ask it again is that we seem to have forgotten the goal of the exercise, and be caught up in a solution without remembering the problem we were trying to solve. SIP work has a history of doing this; it is a large part of why we have a fragmented and difficult to manage family of protocol specifications. It bears asking again before we make things even worse. Do we understand the implications of always delivering multiple H-I items, and do we understand how a UAS can figure out which H-I item or items represents the "correct" parameter set? Because if we do NOT understand these things, then we have failed to meet our actual requirements. I'm not saying H-I doesn't meet the requirements; I'm asking the WG to 1) understand the requirements, and 2) verify that our proposed solution REALLY meets them. Otherwise, we run the risk of producing yet another pointless mechanism that does not solve a problem that we failed to understand. -- Dean From christer.holmberg@ericsson.com Mon May 4 01:05:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3233A6E0C for ; Mon, 4 May 2009 01:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.829 X-Spam-Level: X-Spam-Status: No, score=-5.829 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by3tKsCoMyRU for ; Mon, 4 May 2009 01:05:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 131F53A67D1 for ; Mon, 4 May 2009 01:04:15 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-06-49fea1d2a27a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 57.3E.19078.2D1AEF94; Mon, 4 May 2009 10:05:38 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 10:05:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 10:05:36 +0200 Message-ID: In-Reply-To: <49FA1267.5040204@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft submission: draft-ietf-sipcore-keep-00 (was RE: [sipcore] Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0Nig References: <49FA1267.5040204@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , "SIPCORE" X-OriginalArrivalTime: 04 May 2009 08:05:37.0957 (UTC) FILETIME=[1C09E550:01C9CC8F] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (was RE: Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 08:05:33 -0000 =20 Hi, I've submitted the -00 version of draft-ietf-sipcore-keep. It can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-keep-00.txt I have not done any changes based on Shaun's comments. Any changes will be in the next revision. Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 1. toukokuuta 2009 0:05 > To: SIPCORE;=20 > draft-niemi-sipping-event-throttle@tools.ietf.org;=20 > draft-holmberg-sipcore-keep@tools.ietf.org > Subject: [sipcore] Document Adoption >=20 > [as chair] >=20 > This message announces the formal adoption of two additional=20 > documents as SIPCORE working group items to satisfy two of=20 > our chartered milestones. >=20 > Two weeks ago, the document=20 > draft-niemi-sipping-event-throttle, which was accepted by the=20 > RAI community at the San Franciso SIPPING meeting, was=20 > proposed by the chairs as a candidate to satisfy the=20 > milestone "SIP Events throttling mechanism"[1]. There was one=20 > affirmation of this decision. There was one objection, which=20 > was withdrawn after the question under consideration was=20 > clarified[2]. Given the "previously adopted" status of this=20 > document, and the lack of any remaining objections, the=20 > chairs now consider this a working group document. >=20 > We also had eight positive responses and no objections to=20 > adopting draft-holmberg-sipcore-keep as a working group item=20 > [3] to satisfy the milestone "Mechanism for indicating=20 > support for keep-alives". >=20 > Authors: please submit a draft-ietf-sipcore version of your=20 > document as soon as practical. Also, please keep in mind that=20 > change control now resides with the working group -- you are=20 > advised to make no substantive changes without discussion on=20 > the working group mailing list. >=20 > Thanks! >=20 > /a >=20 > -- > [1] http://www.ietf.org/mail-archive/web/sipcore/current/msg00005.html > [2] http://www.ietf.org/mail-archive/web/sipcore/current/msg00019.html > [3] http://www.ietf.org/mail-archive/web/sipcore/current/msg00021.html > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Mon May 4 03:09:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9855E28C14E for ; Mon, 4 May 2009 03:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.831 X-Spam-Level: X-Spam-Status: No, score=-5.831 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SszOwWiUKGYL for ; Mon, 4 May 2009 03:09:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7E4723A6FCD for ; Mon, 4 May 2009 03:07:28 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-fe-49febead4244 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F5.5D.24713.DAEBEF94; Mon, 4 May 2009 12:08:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 12:08:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 12:08:44 +0200 Message-ID: In-Reply-To: <637C77B6763BB54ABF989B6B21D5323502981F99@sonusmail05.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-holmberg-sipcore-keep-00 (previouslyknown as draft-holmberg-sip-keep) Thread-Index: Acm+bcAszQkyqV++Ts+HPG29TfGFgALlQSopAIXeZxA= References: <637C77B6763BB54ABF989B6B21D5323502981F99@sonusmail05.sonusnet.com> From: "Christer Holmberg" To: "Bharrat, Shaun" , X-OriginalArrivalTime: 04 May 2009 10:08:46.0036 (UTC) FILETIME=[4FAD4940:01C9CCA0] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] [Sip] Draft new version: draft-holmberg-sipcore-keep-00 (previouslyknown as draft-holmberg-sip-keep) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 10:09:13 -0000 Hi Shaun,=20 >> When a UAS that supports the method defined in this specification >> recieves an initial SIP request which contains a "keep" parameter in >> the topmost Via header, and the UAS wants to allow the sender of the >> initial SIP request to send keep-alives towards the UAS during the >> duration of the call, the UAS proxy MUST add a "yes" value to the >> "keep" parameter. In addition the UAS MAY include a Flow-Timer >> header field if the associated initial SIP response. > >Which response is this text referring to when this is for a call? >Does this include the 100 trying? If in the 100 trying, does the keep need to be in all responses to the INVITE? WHat about the Flow-Timer? > >The reason I'm asking is that 100 trying is often generated at a very different place than the other responses. It may or may not be feasible to provide the relevant information in that response. >I'm trying to understand the intent... The keep-alives are always sent between two entities communicating directly with each other (we don't expect SIP proxies for forward STUN requests etc). Also, the parameter is inserted in the Via of the request, so it will be copied into whatever response is generated based on the request. Regards, Christer -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 4/16/2009 4:31 AM To: sipcore@ietf.org; sip@ietf.org Cc: Adam Roach; Gonzalo Camarillo; Mary Barnes Subject: [Sip] Draft new version: draft-holmberg-sipcore-keep-00 (previouslyknown as draft-holmberg-sip-keep) =20 Hi, I've submitted a draft-holmberg-sipcore version of the keep draft. The draft is identical to the previous version (for which Mary sent out the ask-for-support e-mail), but I have added one more example. The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-keep-00.tx t Regards, Christer Ps. I applogize for sending this e-mail to both SIP and SIPCORE, but since everyone may not have subscribed to SIPCORE yet... From christer.holmberg@ericsson.com Mon May 4 03:20:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135F03A6DD3 for ; Mon, 4 May 2009 03:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKwAQz1co7gA for ; Mon, 4 May 2009 03:20:02 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9F3023A690C for ; Mon, 4 May 2009 03:20:01 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-8f-49fec1a53b2b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 28.42.19078.5A1CEF94; Mon, 4 May 2009 12:21:25 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 12:21: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 Date: Mon, 4 May 2009 12:21:24 +0200 Message-ID: In-Reply-To: <9E895F3D-EE68-49E9-B262-034CFE035C15@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Long reply to: Target URI and History Info bis Thread-Index: AcnMfNjhz9h5+6geRMWo/Zuu12hJDwAJBjxA References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com><06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com><49F9718E.4070707@gmail.com><9A564A10-3F22-471A-832B-28117412AD93@softarmor.com><49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> <9E895F3D-EE68-49E9-B262-034CFE035C15@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 04 May 2009 10:21:25.0530 (UTC) FILETIME=[145EDFA0:01C9CCA2] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 10:20:09 -0000 Hi, 4244 in general is kinda messy, and one of the purposes of the proposed 4244bis work is to try to make it more clear. But, as far as the target delivery work is concerned, in my opinion the "goal" is clear: to be able to provide the original target to the UAS (again, the draft explains some cases where it can be useful to be able to do so). Regards, Christer > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 4. toukokuuta 2009 8:55 > To: Christer Holmberg > Cc: Hans Erik van Elburg; SIPCORE > Subject: Re: [sipcore] Long reply to: Target URI and History Info bis >=20 >=20 > On May 3, 2009, at 1:00 PM, Christer Holmberg wrote: >=20 > > > > Hi, > > > > I think the why-is-this-needed questions should have been=20 > asked when=20 > > we decided to start working on this in the first place. And, again,=20 > > the different drafts that have been produced on this topic=20 > DO describe=20 > > different use-cases. >=20 > I asked it then. I asked them as part of the process that=20 > lead to us chartering a deliverable of solving the problem.=20 > The reason I ask it again is that we seem to have forgotten=20 > the goal of the exercise, and be caught up in a solution=20 > without remembering the problem we were trying to solve. >=20 > SIP work has a history of doing this; it is a large part of=20 > why we have a fragmented and difficult to manage family of=20 > protocol specifications. >=20 > It bears asking again before we make things even worse. >=20 > Do we understand the implications of always delivering =20 > multiple H-I items, and do we understand how a UAS can figure=20 > out which H-I item or items represents the "correct" parameter set? >=20 > Because if we do NOT understand these things, then we have=20 > failed to meet our actual requirements. I'm not saying H-I=20 > doesn't meet the requirements; I'm asking the WG to 1)=20 > understand the requirements, and > 2) verify that our proposed solution REALLY meets them. >=20 > Otherwise, we run the risk of producing yet another pointless=20 > mechanism that does not solve a problem that we failed to understand. >=20 >=20 > -- > Dean >=20 From SBharrat@sonusnet.com Mon May 4 05:47:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2F13A69D6 for ; Mon, 4 May 2009 05:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7LnuCNLsj9J for ; Mon, 4 May 2009 05:47:04 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 3AF873A703D for ; Mon, 4 May 2009 05:47:04 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id n44CmPA2006705; Mon, 4 May 2009 08:48:25 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 08:44:42 -0400 Message-ID: <637C77B6763BB54ABF989B6B21D5323502EF24E7@sonusmail05.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-holmberg-sipcore-keep-00 (previouslyknown as draft-holmberg-sip-keep) Thread-Index: Acm+bcAszQkyqV++Ts+HPG29TfGFgALlQSopAIXeZxAAJri/0A== From: "Bharrat, Shaun" To: "Christer Holmberg" , Subject: Re: [sipcore] [Sip] Draft new version: draft-holmberg-sipcore-keep-00 (previouslyknown as draft-holmberg-sip-keep) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:47:10 -0000 Christer: > Also, the parameter is inserted in the Via of the request, so=20 > it will be copied into whatever response is generated based=20 > on the request. I understand that the parameter itself will be copied back. What I am wondering is whether it needs to be set to "yes" in every=20 response or can this work if it is set to "yes" in the final response but not necessarily in the 100 or provisionals. Support of this functionality is not necessarily global (within a box). There are architectures where it will not be possible to know whether support is enabled for that peer at the time or place that=20 the 100 is sent. If no one else envisions a problem along those lines,=20 then I guess my concern is moot. =20 Cheers, Shaun > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Monday, May 04, 2009 6:09 AM > To: Bharrat, Shaun; sipcore@ietf.org > Subject: RE: [Sip] Draft new version:=20 > draft-holmberg-sipcore-keep-00 (previouslyknown as=20 > draft-holmberg-sip-keep) >=20 >=20 > Hi Shaun,=20 >=20 > >> When a UAS that supports the method defined in this specification=20 > >> recieves an initial SIP request which contains a "keep"=20 > parameter in=20 > >> the topmost Via header, and the UAS wants to allow the=20 > sender of the=20 > >> initial SIP request to send keep-alives towards the UAS during the=20 > >> duration of the call, the UAS proxy MUST add a "yes" value to the=20 > >> "keep" parameter. In addition the UAS MAY include a Flow-Timer=20 > >> header field if the associated initial SIP response. > > > >Which response is this text referring to when this is for a call? > >Does this include the 100 trying? If in the 100 trying, does the keep > need to be in all responses to the INVITE? WHat about the Flow-Timer? > > > >The reason I'm asking is that 100 trying is often generated at a very > different place than the other responses. It may or may not=20 > be feasible to provide the relevant information in that response. > >I'm trying to understand the intent... >=20 > The keep-alives are always sent between two entities=20 > communicating directly with each other (we don't expect SIP=20 > proxies for forward STUN requests etc). >=20 > Also, the parameter is inserted in the Via of the request, so=20 > it will be copied into whatever response is generated based=20 > on the request. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: sip-bounces@ietf.org on behalf of Christer Holmberg > Sent: Thu 4/16/2009 4:31 AM > To: sipcore@ietf.org; sip@ietf.org > Cc: Adam Roach; Gonzalo Camarillo; Mary Barnes > Subject: [Sip] Draft new version:=20 > draft-holmberg-sipcore-keep-00 (previouslyknown as=20 > draft-holmberg-sip-keep) > =20 >=20 > Hi, >=20 > I've submitted a draft-holmberg-sipcore version of the keep draft. >=20 > The draft is identical to the previous version (for which=20 > Mary sent out the ask-for-support e-mail), but I have added=20 > one more example. >=20 > The draft can also be found at: >=20 > http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore- > keep-00.tx > t >=20 >=20 > Regards, >=20 > Christer >=20 > Ps. I applogize for sending this e-mail to both SIP and=20 > SIPCORE, but since everyone may not have subscribed to SIPCORE yet... >=20 >=20 >=20 >=20 >=20 >=20 From pkyzivat@cisco.com Mon May 4 05:51:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8BE3A6B7B for ; Mon, 4 May 2009 05:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkRIcG-72Kh5 for ; Mon, 4 May 2009 05:51:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0A2113A6B3E for ; Mon, 4 May 2009 05:51:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,291,1238976000"; d="scan'208";a="180389119" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 04 May 2009 12:53:16 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n44CrFLt008684; Mon, 4 May 2009 05:53:16 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n44Cr5DM006783; Mon, 4 May 2009 12:53:15 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 08:53:15 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 08:53:14 -0400 Message-ID: <49FEE53A.8020009@cisco.com> Date: Mon, 04 May 2009 08:53:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2009 12:53:14.0604 (UTC) FILETIME=[49CD42C0:01C9CCB7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3431; t=1241441596; x=1242305596; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20; bh=KfVPsgr5mBuUQ8U2oVoITSXp04/J978YeOy6pKAfr9Y=; b=NtLA9EWmllvAuK1I0tz6r+H+ZvrQ8vLCekwq+V8SsxSWOf606y7T5LE9EV QA7bPZ0seiLWvU7XUwSCFWT/IfSsHD3ZfWxLB8ygROfyZzDHZO/21xpINuyY P8PuZKPH6q; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:51:51 -0000 Christer, I haven't gone back to 3262 to verify that the words are consistent with what you say, but I trust you and my memory on that. IMO it is not a good thing that there is such variation of meaning of Supported and Require. It would be much better if it was consistent across all options, in the way that Dean has been saying. But I guess that horse is out of the barn. Maybe we can try to enforce a consistent meaning across all *new* uses, but the old ones will have to remain as they are, which makes it more difficult to create a generic mechanism in an implementation. Thanks, Paul Christer Holmberg wrote: > Hi, > >>> The option tag is a means of 1) discovering whether or not the far- >>> end supports a specific extension and of 2) declaring the criticality >>> of understanding that extension relative to satisfying a request and >>> 3) informing the UAC of what extensions were applied to the request >>> in order to generate the response. This is purely a function of >>> capability negotiation, not one of invocation. >>> >>> The extension itself (typically, an extension header field, although >>> there are other types of extensions) is what causes the extension to >>> be invoked. >> Depends a bit how you define extension, but I would argue that if I >> require an extension to be supported on a transaction/dialog by the >> UAS and the UAS accepts the request that this means that for this call >> the UAS behaves as it should according to the extensions >> specification. >> >> Saying that an extensions invokes itself is meaningless to me. >> >> A UAS may choose to only invoke the extension behaviour if it finds >> that the extension is required. That comes close to saying that the >> require:extension invokes the behaviour in the UAS, but it is not at >> all the same. >> >> >> The Require doesn't control whether the UAS invokes the extension. The > UAS may invoke the extension on its own recognizance. Most likely, it > chooses to do so based on 1) the presence of a Supported >> indicator for the extension in a request as evidence that the UAC > supports the extension or the presence of an extension header in the > request that also indicates support in the UAC and 2) support for >> that extension in the UAS. Other extensions may not require support in > the UAC, so may be enacted by this UAS purely on local policy. > > 100rel does not carry any extension headers in the request, nor does > RFC3262 say that the UAC must insert Supported in addition to Require. > > But, RFC3262 DOES say: > > "The UAS MUST send any non-100 provisional response reliably if the > initial request contained a Require header field with the option tag > 100rel." > > So, in my opinion Require:100rel means: > > 1. The UAC supports 100rel (no Suppored needed) > 2. The UAS MUST use the extension (if sending non-100 provisional > responses). > > I have nothing against saying that the definition of each option-tag > should specify how it is used, and what Require really means as far as > the UAS is concerned, but I don't think the generic definition of > Supported and Require that you are proposing fits all cases. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From hannu.hietalahti@nokia.com Mon May 4 06:21:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38DA3A69DB for ; Mon, 4 May 2009 06:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uS2HQZ7jRSu for ; Mon, 4 May 2009 06:21:19 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 183EC3A7035 for ; Mon, 4 May 2009 06:20:42 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n44DLPra019900; Mon, 4 May 2009 08:22:04 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 16:21:59 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 16:21:53 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 16:21:48 +0300 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 4 May 2009 15:21:47 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Mon, 4 May 2009 15:21:48 +0200 From: To: , Date: Mon, 4 May 2009 15:21:46 +0200 Thread-Topic: Summary of issues around registering feature tags Thread-Index: AcnI7dRP+ANCuhgaQOusWTKvXZ1fLgDzRWUg Message-ID: <15443028349C3C44BA819EB51B3B4F3C27F3837837@NOK-EUMSG-01.mgdnok.nokia.com> References: <26896AF9-3AB9-4523-B133-72179A2D68F4@cisco.com> In-Reply-To: <26896AF9-3AB9-4523-B133-72179A2D68F4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 May 2009 13:21:48.0726 (UTC) FILETIME=[477F8560:01C9CCBB] X-Nokia-AV: Clean X-Mailman-Approved-At: Mon, 04 May 2009 07:18:27 -0700 Cc: gonzalo.camarillo@ericsson.com Subject: Re: [sipcore] Summary of issues around registering feature tags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 13:21:20 -0000 Thanks Cullen, this solves some of the action points from the previous 3GPP - IETF telco (= the good news) Unfortunately it leaves more work to do (the bad news) It seems best to close the AP's in 3GPP - IETF meeting later today, as this= task will need to be carried out by someone who is willing to contribute a= nd to drive the work in IETF. BR, Hannu Hietalahti 3GPP TSG CT Chairman tel: +358 40 5021724 =20 >-----Original Message----- >From: ext Cullen Jennings [mailto:fluffy@cisco.com]=20 >Sent: 29 April, 2009 20:13 >To: sipcore@ietf.org >Cc: Robert Sparks; Gonzalo Camarillo; Hietalahti Hannu=20 >(Nokia-CIC/Oulu); Adam Roach; Mary Barnes >Subject: Summary of issues around registering feature tags > > >3GPP has requested that IANA register two new feature tags >(g.3gpp.icsi-ref and g.3gpp.iari-ref) in the global tree. Per >RFC 2506 (Section 3.1.2), the policy for registrations in the >global tree is expert review. > >This is the description of the feature tags to be registered: > >"Each value of the Application Reference media feature-tag=20 >indicates the >software applications supported by the agent. The values for this tag >equal the IMS communication Service Identifier (ICSI) and IMS >Application Reference Identifier (IARI) values supported by >the agent. The Application Reference media feature tag is >defined to fulfill the requirements for forking to an appropriate UE =20 >when >multiple UEs are registered and dispatch to an appropriate application >within the UE based upon the IMS communication Service Identifier >(ICSI) and IMS Application Reference Identifier (IARI) values as >stated in 3GPP TS 23.228. Multiple tag-values can be included in the >Application Reference media feature-tag." > >Section 12.1 of RFC 3840 states that feature tags that are=20 >applicable to >SIP and whose meaning is only defined within that usage are to be >registered in the SIP tree. Since these feature tags are to be=20 >used only >within the context of SIP, they would need to be registered in the SIP >tree and not in the global tree. The policy for registrations=20 >in the SIP >tree is IETF Consensus. That is, registrations need to be documented in >an RFC approved by the IESG. > >Regardless of the tree these feature tags would need to be registered >in, the expert reviewer indicated that this tags will not=20 >contain simple >features but rather more complex services or feature sets. Therefore, >the expert reviewer did not find it appropriate to register=20 >them because >Section 2.1 of RFC 2506 states that "media feature tags represent >individual and simple characteristics" and that "each media feature tag >identifies a single characteristic". > >Additionally, Section 6 of >draft-ietf-sipping-service-identification-03.txt describes the=20 >perils of >performing declarative service identifications. The way these feature >tags are described make them look as if they were going to be used to >perform such declarative service identifications. > >Consequently, 3GPP is encouraged to submit an Internet Draft describing >the use of these feature tags so that they can be registered in the SIP >tree. Such Internet Draft needs to address the issues discussed in >draft-ietf-sipping-service-identification-03.txt clarifying why these >tags will not be used to perform declarative service identifications. > >Cullen > >Thank you to the people that helped prepare this summary. > >= From root@core3.amsl.com Mon May 4 12:15:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 660BC3A70EB; Mon, 4 May 2009 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090504191501.660BC3A70EB@core3.amsl.com> Date: Mon, 4 May 2009 12:15:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:15:01 -0000 --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 Core Working Group of the IETF. Title : Indication of support for keep-alive Author(s) : C. Holmberg Filename : draft-ietf-sipcore-keep-00.txt Pages : 11 Date : 2009-05-04 This specification defines a new SIP Via header parameter, "keep" which SIP entities can use to indicate support of the NAT keep-alive techniques defined in SIP Outbound, in cases where the Outbound procedures are not supported or cannot be applied. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sipcore-keep-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-04120910.I-D@ietf.org> --NextPart-- From christer.holmberg@ericsson.com Mon May 4 13:10:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938F73A6BCE for ; Mon, 4 May 2009 13:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.235 X-Spam-Level: X-Spam-Status: No, score=-5.235 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSSDU75CZCQK for ; Mon, 4 May 2009 13:10:03 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EC2843A6B1F for ; Mon, 4 May 2009 13:10:02 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-05-49ff4bef67b6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 15.4C.24713.FEB4FF94; Mon, 4 May 2009 22:11:27 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 22:11:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 22:11:26 +0200 Message-ID: In-Reply-To: <49FEE53A.8020009@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnMt05B4O/uKDSETgiH4HPt5YVd1AAOmTnQ References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 04 May 2009 20:11:26.0791 (UTC) FILETIME=[812A9D70:01C9CCF4] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:10:04 -0000 Hi, I don't think there is an issue with Supported. Supported:foo means "I support foo" - nothing more, nothing less. When it comes to Require:foo, it of course means "I require you to support foo". BUT, whether Require:foo also means "I require you to always use foo", "I require you to use foo in specific situations", or "I require you to support foo, but you don't have to use it" I think depends very much on the extension, and choosing one of the above meanings for all future extensions could be very restrictive. In addition, there also seems to be different opinions on whehter Require:foo also indicates that the sender supports it or not, or only requires the receiver to support it. In most cases I think it can be assumed that the sender also supports the extension, because the sender would somehow be involved in the procedures associated with the extension. But, there COULD of course be an extension which is only affects the receiver, and does not require any kind of support by the sender. And, I think we have more or less the same issues/questions with Proxy-Require as we have for Require. Regards, Christer =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Monday, May 04, 2009 3:53 PM To: Christer Holmberg Cc: Dean Willis; Hans Erik van Elburg; SIPCORE Subject: Re: [sipcore] Question on Require in responses Christer, I haven't gone back to 3262 to verify that the words are consistent with what you say, but I trust you and my memory on that. IMO it is not a good thing that there is such variation of meaning of Supported and Require. It would be much better if it was consistent across all options, in the way that Dean has been saying. But I guess that horse is out of the barn. Maybe we can try to enforce a consistent meaning across all *new* uses, but the old ones will have to remain as they are, which makes it more difficult to create a generic mechanism in an implementation. Thanks, Paul Christer Holmberg wrote: > Hi, >=20 >>> The option tag is a means of 1) discovering whether or not the far-=20 >>> end supports a specific extension and of 2) declaring the=20 >>> criticality of understanding that extension relative to satisfying a >>> request and >>> 3) informing the UAC of what extensions were applied to the request=20 >>> in order to generate the response. This is purely a function of=20 >>> capability negotiation, not one of invocation. >>> >>> The extension itself (typically, an extension header field, although >>> there are other types of extensions) is what causes the extension to >>> be invoked. >> Depends a bit how you define extension, but I would argue that if I=20 >> require an extension to be supported on a transaction/dialog by the=20 >> UAS and the UAS accepts the request that this means that for this=20 >> call the UAS behaves as it should according to the extensions=20 >> specification. >> >> Saying that an extensions invokes itself is meaningless to me. >> >> A UAS may choose to only invoke the extension behaviour if it finds=20 >> that the extension is required. That comes close to saying that the=20 >> require:extension invokes the behaviour in the UAS, but it is not at=20 >> all the same. >> >> >> The Require doesn't control whether the UAS invokes the extension.=20 >> The > UAS may invoke the extension on its own recognizance. Most likely, it > chooses to do so based on 1) the presence of a Supported >> indicator for the extension in a request as evidence that the UAC > supports the extension or the presence of an extension header in the=20 > request that also indicates support in the UAC and 2) support for >> that extension in the UAS. Other extensions may not require support=20 >> in > the UAC, so may be enacted by this UAS purely on local policy. >=20 > 100rel does not carry any extension headers in the request, nor does > RFC3262 say that the UAC must insert Supported in addition to Require. >=20 > But, RFC3262 DOES say: >=20 > "The UAS MUST send any non-100 provisional response reliably if the=20 > initial request contained a Require header field with the option tag=20 > 100rel." >=20 > So, in my opinion Require:100rel means: >=20 > 1. The UAC supports 100rel (no Suppored needed) 2. The UAS MUST use=20 > the extension (if sending non-100 provisional responses). >=20 > I have nothing against saying that the definition of each option-tag=20 > should specify how it is used, and what Require really means as far as > the UAS is concerned, but I don't think the generic definition of=20 > Supported and Require that you are proposing fits all cases. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Mon May 4 13:17:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A0828C238 for ; Mon, 4 May 2009 13:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.834 X-Spam-Level: X-Spam-Status: No, score=-5.834 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjJCXbAvsKII for ; Mon, 4 May 2009 13:17:33 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D9B8528C235 for ; Mon, 4 May 2009 13:17:32 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-6e-49ff4db1b4a6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 77.7C.24713.1BD4FF94; Mon, 4 May 2009 22:18:57 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 22:18:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 22:18:56 +0200 Message-ID: In-Reply-To: <637C77B6763BB54ABF989B6B21D5323502EF24E7@sonusmail05.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-holmberg-sipcore-keep-00 (previouslyknown as draft-holmberg-sip-keep) Thread-Index: Acm+bcAszQkyqV++Ts+HPG29TfGFgALlQSopAIXeZxAAJri/0AAP2kFQ References: <637C77B6763BB54ABF989B6B21D5323502EF24E7@sonusmail05.sonusnet.com> From: "Christer Holmberg" To: "Bharrat, Shaun" , X-OriginalArrivalTime: 04 May 2009 20:18:57.0204 (UTC) FILETIME=[8DA22F40:01C9CCF5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] [Sip] Draft new version: draft-holmberg-sipcore-keep-00 (previouslyknown as draft-holmberg-sip-keep) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:17:34 -0000 Hi,=20 >>Also, the parameter is inserted in the Via of the request, so it will be copied into whatever response is generated based on the request. > >I understand that the parameter itself will be copied back. What I am wondering is whether it needs to be set to "yes" in every response or can this work if it is set to "yes" in the final response but=20 >not necessarily in the 100 or provisionals. > >Support of this functionality is not necessarily global (within a box). There are architectures where it will not be possible to know whether support is enabled for that peer at the time or place that=20 >the 100 is sent. If no one else envisions a problem along those lines, then I guess my concern is moot. =20 Since 100 responses are hop-to-hop, they are always generated by the UAS, so I guess the UAS could choose not to insert a "yes" value in the received Via when creating the response. We don't use 100 for other types of negotiations either, so I see no harm in not inserting "yes" in the 100 response, but still insert it in the forwarded request so it will be present in all other responses, generated by the remote endpoint. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, May 04, 2009 6:09 AM > To: Bharrat, Shaun; sipcore@ietf.org > Subject: RE: [Sip] Draft new version:=20 > draft-holmberg-sipcore-keep-00 (previouslyknown as > draft-holmberg-sip-keep) >=20 >=20 > Hi Shaun, >=20 > >> When a UAS that supports the method defined in this specification=20 > >> recieves an initial SIP request which contains a "keep" > parameter in > >> the topmost Via header, and the UAS wants to allow the > sender of the > >> initial SIP request to send keep-alives towards the UAS during the=20 > >> duration of the call, the UAS proxy MUST add a "yes" value to the=20 > >> "keep" parameter. In addition the UAS MAY include a Flow-Timer=20 > >> header field if the associated initial SIP response. > > > >Which response is this text referring to when this is for a call? > >Does this include the 100 trying? If in the 100 trying, does the keep > need to be in all responses to the INVITE? WHat about the Flow-Timer? > > > >The reason I'm asking is that 100 trying is often generated at a very > different place than the other responses. It may or may not be=20 > feasible to provide the relevant information in that response. > >I'm trying to understand the intent... >=20 > The keep-alives are always sent between two entities communicating=20 > directly with each other (we don't expect SIP proxies for forward STUN > requests etc). >=20 > Also, the parameter is inserted in the Via of the request, so it will=20 > be copied into whatever response is generated based on the request. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: sip-bounces@ietf.org on behalf of Christer Holmberg > Sent: Thu 4/16/2009 4:31 AM > To: sipcore@ietf.org; sip@ietf.org > Cc: Adam Roach; Gonzalo Camarillo; Mary Barnes > Subject: [Sip] Draft new version:=20 > draft-holmberg-sipcore-keep-00 (previouslyknown as > draft-holmberg-sip-keep) > =20 >=20 > Hi, >=20 > I've submitted a draft-holmberg-sipcore version of the keep draft. >=20 > The draft is identical to the previous version (for which Mary sent=20 > out the ask-for-support e-mail), but I have added one more example. >=20 > The draft can also be found at: >=20 > http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore- > keep-00.tx > t >=20 >=20 > Regards, >=20 > Christer >=20 > Ps. I applogize for sending this e-mail to both SIP and SIPCORE, but=20 > since everyone may not have subscribed to SIPCORE yet... >=20 >=20 >=20 >=20 >=20 >=20 From dworley@nortel.com Mon May 4 15:01:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77EFE3A69B4 for ; Mon, 4 May 2009 15:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OKcax0ncFhx for ; Mon, 4 May 2009 15:01:40 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 610963A6A10 for ; Mon, 4 May 2009 15:01:31 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n44M1qo24404; Mon, 4 May 2009 22:01:53 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 18:02:44 -0400 From: "Dale Worley" To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FA32E9.3070509@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 04 May 2009 18:02:43 -0400 Message-Id: <1241474563.3833.23.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2009 22:02:44.0247 (UTC) FILETIME=[0D3D8A70:01C9CD04] Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 22:01:41 -0000 On Fri, 2009-05-01 at 08:10 +0100, Elwell, John wrote: > Even if there are no absolute guarantees, there is a general expectation > that things will work if used in the way described in the RFC where the > option tag is defined. For example, if receipt of a replaces option tag > does not mean that the Replaces header field is likely to be supported > if received in future request from outside the dialog, things like > attended call transfer would not work with any degree of reliability. > > So I think the scope of an option tag is defined by the RFC where the > option tag is defined. This is an exceedingly good description of the state of practice. But the RFCs aren't written particularly well with this concept in mind. Consider "eventlist". You describe its scope quite cleanly: - eventlist - use in [Supported in] a SUBSCRIBE request indicates support for this feature in received NOTIFY requests on dialogs created from that SUBSCRIBE request; But the text of the RFC doesn't seem to *say* that. As far as I can tell (without reading all of it), (normatively) the RFC says that it creates the "eventlist" tag, and then says (explicitly non-normatively): Any client that supports the event list extension will include an option tag of "eventlist" in a "Supported" header field of every SUBSCRIBE message for a subscription for which it is willing to process a list. If the subscription is made to a URI that represents a list, the RLS will include "eventlist" in a "Require" header field of the response to the SUBSCRIBE, and in all NOTIFY messages within that subscription. The first sentence is close to what you have written, but as you note, that fact needs to be stated normatively. The second sentence talks about "Require" in a response, which is far as I can tell, has no defined meaning. We've not been at all good about defining the scope of meaning of option tags, and beyond that, we haven't been careful to regularize and standardize the scopes, so that each usage doesn't need custom code to be handled. Dale From dworley@nortel.com Mon May 4 15:06:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8B43A6C6D for ; Mon, 4 May 2009 15:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxIE7qKcucM7 for ; Mon, 4 May 2009 15:06:58 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1953E3A687F for ; Mon, 4 May 2009 15:06:58 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n44M8Jb13301; Mon, 4 May 2009 22:08:19 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 18:08:02 -0400 From: "Dale Worley" To: Christer Holmberg In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 04 May 2009 18:08:02 -0400 Message-Id: <1241474882.3833.29.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2009 22:08:02.0860 (UTC) FILETIME=[CB2606C0:01C9CD04] Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 22:06:59 -0000 On Mon, 2009-05-04 at 22:11 +0200, Christer Holmberg wrote: > In addition, there also seems to be different opinions on whehter > Require:foo also indicates that the sender supports it or not, or only > requires the receiver to support it. In most cases I think it can be > assumed that the sender also supports the extension, because the sender > would somehow be involved in the procedures associated with the > extension. But, there COULD of course be an extension which is only > affects the receiver, and does not require any kind of support by the > sender. I think it would be best, and also safe, to *not* have "Require: foo" imply "Supported: foo". Of course, in most cases, the first without the second would be useless. as the response to the request would include information that the UAC could not process usefully. But there is no reason that an extension need be symmetric between the UAC and UAS sides of a transaction, or that in an ongoing dialog, that using an extension for requests going in one direction requires using the extension for requests going in the other direction. Dale From root@core3.amsl.com Mon May 4 15:15:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 62CC83A6C6D; Mon, 4 May 2009 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090504221501.62CC83A6C6D@core3.amsl.com> Date: Mon, 4 May 2009 15:15:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 22:15:01 -0000 --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 Core Working Group of the IETF. Title : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sipcore-sec-flows-00.txt Pages : 59 Date : 2009-05-04 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sipcore-sec-flows-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-04151342.I-D@ietf.org> --NextPart-- From dean.willis@softarmor.com Mon May 4 18:56:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFEBE3A6A13 for ; Mon, 4 May 2009 18:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KDAFDwCIIiE for ; Mon, 4 May 2009 18:56:57 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EBD113A68AF for ; Mon, 4 May 2009 18:56:56 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n451vo7U027119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 20:57:52 -0500 Message-Id: <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 20:57:45 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 01:56:58 -0000 On May 4, 2009, at 3:11 PM, Christer Holmberg wrote: > > Hi, > > I don't think there is an issue with Supported. Supported:foo means "I > support foo" - nothing more, nothing less. I agree 100%. > > > When it comes to Require:foo, it of course means "I require you to > support foo". Right so far. > > > BUT, whether Require:foo also means "I require you to always use foo", > "I require you to use foo in specific situations", or "I require you > to > support foo, but you don't have to use it" I think depends very much > on > the extension, and choosing one of the above meanings for all future > extensions could be very restrictive. How about the authorization question: Christer requires the UAS to support and use the Foo: extension, but Christer is not authorized to use the Foo: extension at this UAS. UAS would be willing to process the request for Christer without using Foo:, but SIP provides no mechanism for UAS to tell Christer not to use Foo:. Consequently, we need that "very restrictive" model, or we need new feature-authorization-negotiation capabilities. > In addition, there also seems to be different opinions on whehter > Require:foo also indicates that the sender supports it or not, or only > requires the receiver to support it. In most cases I think it can be > assumed that the sender also supports the extension, because the > sender > would somehow be involved in the procedures associated with the > extension. But, there COULD of course be an extension which is only > affects the receiver, and does not require any kind of support by the > sender. Bingo. That's why it should also be in the sender's uipported:, and any extension that triggers on the REQUIRE to indicate support in the UAC is just badly written. And yes, we have erroneous RFCs. Just because we wrote it that way doesn't make it right -- either something has to change in RFC 3261, or something has to change in the RFCs that misuse Require. > And, I think we have more or less the same issues/questions with > Proxy-Require as we have for Require. Perhaps not quite so much, as we have written so few proxy-extensions, but probably true. -- Dean From dean.willis@softarmor.com Mon May 4 19:05:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10C53A704E for ; Mon, 4 May 2009 19:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1+TDq6IOVE5 for ; Mon, 4 May 2009 19:05:00 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CC5B93A7132 for ; Mon, 4 May 2009 19:05:00 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4526PUQ027174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 21:06:26 -0500 Message-Id: From: Dean Willis To: Dale Worley In-Reply-To: <1241474563.3833.23.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 21:06:19 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FA32E9.3070509@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> <1241474563.3833.23.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 02:05:01 -0000 On May 4, 2009, at 5:02 PM, Dale Worley wrote: > > The first sentence is close to what you have written, but as you note, > that fact needs to be stated normatively. The second sentence talks > about "Require" in a response, which is far as I can tell, has no > defined meaning. "Require" in a response has a defined meaning: It means that the referenced extension was applied in formulating the response. Of course, we have erroneous RFCs (including some I edited, dang it!) that don't do this right. To quote RFC 3261 8.2.4 Applying Extensions: > Any extensions applied to a non-421 response MUST be listed in a > Require header field included in the response. Note that the following sentence, also from that section, is under debate -- I think it is not justifiable and should allow informational- track RFCs. > Of course, the server MUST NOT apply extensions not listed in the > Supported header field in the request. As a result of this, the > Require header field in a response will only ever contain option > tags defined in standards- track RFCs. -- Dean From dean.willis@softarmor.com Mon May 4 19:06:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38A8428C167 for ; Mon, 4 May 2009 19:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0ZezMs4d5Cn for ; Mon, 4 May 2009 19:06:41 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 82C3A28C10B for ; Mon, 4 May 2009 19:06:30 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4527o07027196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 21:07:51 -0500 Message-Id: <4732811D-A70A-4E6D-92D7-B44AD3BB3F2D@softarmor.com> From: Dean Willis To: Dean Willis In-Reply-To: <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 21:07:44 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 02:06:42 -0000 On May 4, 2009, at 8:57 PM, Dean Willis wrote: > > On May 4, 2009, at 3:11 PM, Christer Holmberg wrote: > >> >> Hi, >> >> I don't think there is an issue with Supported. Supported:foo means >> "I >> support foo" - nothing more, nothing less. > > I agree 100%. > >> >> >> When it comes to Require:foo, it of course means "I require you to >> support foo". > > Right so far. > >> >> >> BUT, whether Require:foo also means "I require you to always use >> foo", >> "I require you to use foo in specific situations", or "I require >> you to >> support foo, but you don't have to use it" I think depends very >> much on >> the extension, and choosing one of the above meanings for all future >> extensions could be very restrictive. > > How about the authorization question: Christer requires the UAS to > support and use the Foo: extension, but Christer is not authorized > to use the Foo: extension at this UAS. UAS would be willing to > process the request for Christer without using Foo:, but SIP > provides no mechanism for UAS to tell Christer not to use Foo:. > > Consequently, we need that "very restrictive" model, or we need new > feature-authorization-negotiation capabilities. > > >> In addition, there also seems to be different opinions on whehter >> Require:foo also indicates that the sender supports it or not, or >> only >> requires the receiver to support it. In most cases I think it can be >> assumed that the sender also supports the extension, because the >> sender >> would somehow be involved in the procedures associated with the >> extension. But, there COULD of course be an extension which is only >> affects the receiver, and does not require any kind of support by the >> sender. > > Bingo. That's why it should also be in the sender's uipported:, and > any extension that triggers on the REQUIRE to indicate support in > the UAC is just badly written. > Oops - it should be in the senders "Supported". If I could just type, I would only look half as stupid. Okay, maybe 3/4. > And yes, we have erroneous RFCs. Just because we wrote it that way > doesn't make it right -- either something has to change in RFC 3261, > or something has to change in the RFCs that misuse Require. > > >> And, I think we have more or less the same issues/questions with >> Proxy-Require as we have for Require. > > Perhaps not quite so much, as we have written so few proxy- > extensions, but probably true. > > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Mon May 4 19:37:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7B13A6A1A for ; Mon, 4 May 2009 19:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.645 X-Spam-Level: X-Spam-Status: No, score=-4.645 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFzVNR-h3eBZ for ; Mon, 4 May 2009 19:37:29 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 869533A6819 for ; Mon, 4 May 2009 19:37:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,294,1238976000"; d="scan'208";a="43400761" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 May 2009 02:38:54 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n452csq2011174; Mon, 4 May 2009 22:38:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n452csrp005675; Tue, 5 May 2009 02:38:54 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 22:38:54 -0400 Received: from [10.86.255.197] ([10.86.255.197]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 22:38:53 -0400 Message-ID: <49FFA6BC.1060207@cisco.com> Date: Mon, 04 May 2009 22:38:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> In-Reply-To: <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2009 02:38:53.0544 (UTC) FILETIME=[A14F9E80:01C9CD2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2774; t=1241491134; x=1242355134; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20 |To:=20Dean=20Willis=20; bh=dYWhZSEcsVeVuH+BmKGW6Or4UfcrSyFxzN/4CBaGFTo=; b=byerJWzcCJblDH3pCv/hW3MbQ4uj+oOs5PBZA1lRS+bsl5aLCtgkvC8RTB G6iRtkqPRfdal9HSSwHYiHeHhN02Huh2Mjrvsogew3RQAsxGUDj3VpwsiRb4 3ImvVnS8Ew; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 02:37:30 -0000 Dean Willis wrote: > > On May 4, 2009, at 3:11 PM, Christer Holmberg wrote: > >> >> Hi, >> >> I don't think there is an issue with Supported. Supported:foo means "I >> support foo" - nothing more, nothing less. > > I agree 100%. What about those cases where a UAC and UAS must both "support" it for it to be used, but where the roles are asymmetric? There are lots of those. For instance, eventlist. Do you only advertise support if you can *receive* an eventlist in a NOTIFY? What do you say if you are capable of sending eventlist in a NOTIFY, but not of receiving it. (Perhaps because you never subscribe to anything.) Thanks, Paul >> When it comes to Require:foo, it of course means "I require you to >> support foo". > > Right so far. > >> >> >> BUT, whether Require:foo also means "I require you to always use foo", >> "I require you to use foo in specific situations", or "I require you to >> support foo, but you don't have to use it" I think depends very much on >> the extension, and choosing one of the above meanings for all future >> extensions could be very restrictive. > > How about the authorization question: Christer requires the UAS to > support and use the Foo: extension, but Christer is not authorized to > use the Foo: extension at this UAS. UAS would be willing to process the > request for Christer without using Foo:, but SIP provides no mechanism > for UAS to tell Christer not to use Foo:. > > Consequently, we need that "very restrictive" model, or we need new > feature-authorization-negotiation capabilities. > > >> In addition, there also seems to be different opinions on whehter >> Require:foo also indicates that the sender supports it or not, or only >> requires the receiver to support it. In most cases I think it can be >> assumed that the sender also supports the extension, because the sender >> would somehow be involved in the procedures associated with the >> extension. But, there COULD of course be an extension which is only >> affects the receiver, and does not require any kind of support by the >> sender. > > Bingo. That's why it should also be in the sender's uipported:, and any > extension that triggers on the REQUIRE to indicate support in the UAC is > just badly written. > > And yes, we have erroneous RFCs. Just because we wrote it that way > doesn't make it right -- either something has to change in RFC 3261, or > something has to change in the RFCs that misuse Require. > > >> And, I think we have more or less the same issues/questions with >> Proxy-Require as we have for Require. > > Perhaps not quite so much, as we have written so few proxy-extensions, > but probably true. > > -- > Dean > From christer.holmberg@ericsson.com Mon May 4 22:38:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA0A3A6C96 for ; Mon, 4 May 2009 22:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.236 X-Spam-Level: X-Spam-Status: No, score=-5.236 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P92ipLC1t8WY for ; Mon, 4 May 2009 22:38:40 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7325A3A6C0F for ; Mon, 4 May 2009 22:38:40 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-1c-49ffd133e2dc Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id E9.24.19078.331DFF94; Tue, 5 May 2009 07:40:04 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 07:40: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 Date: Tue, 5 May 2009 07:40:02 +0200 Message-ID: In-Reply-To: <1241474882.3833.29.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnNBNmHkAETXOfISi2/3yhj+V0slAAPhRJQ References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> <1241474882.3833.29.camel@victoria-pingtel-com.us.nortel.com> From: "Christer Holmberg" To: "Dale Worley" X-OriginalArrivalTime: 05 May 2009 05:40:03.0944 (UTC) FILETIME=[F0930680:01C9CD43] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 05:38:41 -0000 Hi,=20 >>In addition, there also seems to be different opinions on whehter=20 >>Require:foo also indicates that the sender supports it or=20 >>not, or only requires the receiver to support it. In most cases I think=20 >>it can be assumed that the sender also supports the extension, because the=20 >>sender would somehow be involved in the procedures associated with the >>extension. But, there COULD of course be an extension which is only=20 >>affects the receiver, and does not require any kind of support by the=20 >>sender. >=20 >I think it would be best, and also safe, to *not* have "Require: foo" >imply "Supported: foo". Of course, in most cases, the first=20 >without the second would be useless. as the response to the=20 >request would include information that the UAC could not=20 >process usefully. But there is no reason that an extension=20 >need be symmetric between the UAC and UAS sides of a=20 >transaction, or that in an ongoing dialog, that using an=20 >extension for requests going in one direction requires using=20 >the extension for requests going in the other direction. Currently I wonder if there is a single extension which requires the UAC to send Supported:foo in addition to Require:foo to indicate that the UAC also supports the extension. The reason is probably that most (all?) extensions do require some kind of support from both the UAC and UAS. Regards, Christer From christer.holmberg@ericsson.com Mon May 4 23:09:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0873A6993 for ; Mon, 4 May 2009 23:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.835 X-Spam-Level: X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2COGF6u--do for ; Mon, 4 May 2009 23:09:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1C00B3A68D9 for ; Mon, 4 May 2009 23:09:08 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-07-49ffd8596911 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 23.96.19078.958DFF94; Tue, 5 May 2009 08:10:34 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 08:10:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 08:10:32 +0200 Message-ID: In-Reply-To: <4732811D-A70A-4E6D-92D7-B44AD3BB3F2D@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnNJk6iJQIaBvoMR5KyquZX9tEZNgAIVEug References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> <4732811D-A70A-4E6D-92D7-B44AD3BB3F2D@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 05 May 2009 06:10:33.0664 (UTC) FILETIME=[332C2400:01C9CD48] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 06:09:10 -0000 Hi,=20 >>>In addition, there also seems to be different opinions on whehter=20 >>>Require:foo also indicates that the sender supports it or not, or=20 >>>only requires the receiver to support it. In most cases I think it=20 >>>can be assumed that the sender also supports the extension, because=20 >>>the sender would somehow be involved in the procedures associated=20 >>>with the extension. But, there COULD of course be an extension which=20 >>>is only affects the receiver, and does not require any kind of=20 >>>support by the sender. >> >>Bingo. That's why it should also be in the sender's uipported:, and=20 >>any extension that triggers on the REQUIRE to indicate support in the=20 >>UAC is just badly written. >>=20 >Oops - it should be in the senders "Supported". If I could=20 >just type, I would only look half as stupid. Okay, maybe 3/4. Doesn't that mean that most extensions are badly written? =20 >>And yes, we have erroneous RFCs. Just because we wrote it that way=20 >>doesn't make it right -- either something has to change in RFC 3261,=20 >>or something has to change in the RFCs that misuse Require. Some extensions are already widely deployed, so I don't think we can do very much about those.=20 Regards, Christer From ya-ching.tan@nsn.com Tue May 5 04:26:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27FA3A6C3F for ; Tue, 5 May 2009 04:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.339 X-Spam-Level: X-Spam-Status: No, score=-5.339 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHGcFAGbFGHM for ; Tue, 5 May 2009 04:26:38 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 41E613A682B for ; Tue, 5 May 2009 04:26:16 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n45BRQN6029903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 May 2009 13:27:26 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n45BRPue019942; Tue, 5 May 2009 13:27:26 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 13:27: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 Date: Tue, 5 May 2009 13:27:25 +0200 Message-ID: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (was RE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YA= References: <49FA1267.5040204@nostrum.com> From: "Tan, Ya Ching (NSN - DE/Munich)" To: "ext Christer Holmberg" X-OriginalArrivalTime: 05 May 2009 11:27:25.0701 (UTC) FILETIME=[773AC350:01C9CD74] Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (was RE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 11:26:39 -0000 =20 Some comments : 1. Please update all references of [I-D.ietf-behave-rfc3489bis] to RFC 5389. 2. It is stated under Section 6 (Server behavior) that "The UAS MUST also process double-CRLF keep-alives", but there is no mention of the requirement to support the CRLF keep alive technic under Section 5 (Client behavior). 3. The draft repeatedly uses the term 'initial SIP request'. What is the definition of this as it is not a known technical term in SIP [RFC 3261]. The sentence in Section 5 "If the UAC wishes to apply keep-alive for future calls, it MUST insert a "keep" Via parameter in the initial SIP request of those calls". This seems to imply that 'initial SIP request' means the initial INVITE. 'Initial INVITE' is what RFC 3261 calls the dialog-initiating INVITE. Should the "keep" parameter in Via only be used in initial REGISTER and initial INVITE ? 4. What is the definition of 'initial SIP response' used throughout the draft ? I take it that the "keep=3Dyes" parameter is only meaningful = and useful if the response is a 2xx. Is that right ? 5. The Via headers in the REGISTER/INVITE sent by the Proxy P1 are in the wrong order. "Via:P1" should be the topmost Via header. 6. Section 5 : "... and the UAC wants to send keep-alives towards the next hop, the entity MUST include a "keep" Via parameter in the SIP request". It should be "... the entity MUST include a "keep" parameter in the Via header it inserts into the SIP request". 7. Section 5 : "If the Via header header in the initial SIP responses contains a "keep" parameter with a "yes" value..." should read "If the top Via header in the 2xx SIP response contains a "keep" parameter with a "yes" value...". 8. Third paragraph of Section 5 : "If the initial SIP response contains a Flow-Timer header...". In the SIP outbound draft, the Flow-Timer header is only meant to be present in 'a successful registration response' (i.e. in a REGISTER response). 9. Typos in Section 9.1 and 9.2 : "recommented" -> "recommended". Regards, Ya-Ching From christer.holmberg@ericsson.com Tue May 5 05:02:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C263A6CA2 for ; Tue, 5 May 2009 05:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.537 X-Spam-Level: X-Spam-Status: No, score=-5.537 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-SccigPCd+u for ; Tue, 5 May 2009 05:02:15 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EDCBA3A6C2B for ; Tue, 5 May 2009 05:02:14 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-3d-4a002b1bb6f2 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 41.1E.24713.C1B200A4; Tue, 5 May 2009 14:03:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 14:03:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 14:03:39 +0200 Message-ID: In-Reply-To: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (was RE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAA== References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> From: "Christer Holmberg" To: "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 05 May 2009 12:03:39.0984 (UTC) FILETIME=[87340500:01C9CD79] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (was RE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 12:02:16 -0000 Hi,=20 >1. Please update all references of [I-D.ietf-behave-rfc3489bis] to RFC 5389. Will do. >2. It is stated under Section 6 (Server behavior) that "The=20 >UAS MUST also process double-CRLF keep-alives", but there is=20 >no mention of the requirement to support the CRLF keep alive=20 >technic under Section 5 (Client behavior). I'll look into that. >3. The draft repeatedly uses the term 'initial SIP request'. =20 >What is the definition of this as it is not a known technical=20 >term in SIP [RFC 3261]. The sentence in Section 5 "If the=20 >UAC wishes to apply keep-alive for future calls, it MUST=20 >insert a "keep" Via parameter in the initial SIP request of=20 >those calls". This seems to imply that 'initial SIP request'=20 >means the initial INVITE. 'Initial INVITE' is what RFC 3261=20 >calls the dialog-initiating INVITE. Should the "keep"=20 >parameter in Via only be used in initial REGISTER and initial INVITE ? I think that is the current assumption, yes, but I am not sure whether we need to make that restriction. Regarding the usage of "initial SIP request", I guess it should say "initial SIP dialog request", or something like that. I think similar wording is used in some places of the document. >4. What is the definition of 'initial SIP response' used=20 >throughout the draft ? I take it that the "keep=3Dyes"=20 >parameter is only meaningful and useful if the response is a=20 >2xx. Is that right ? I guess it should be "response to the initial SIP request", or something like that. In addition to 2xx, the keep=3Dyes can also be useful in provisional responses. =20 >5. The Via headers in the REGISTER/INVITE sent by the Proxy=20 >P1 are in the wrong order. "Via:P1" should be the topmost Via header. True. I noted that already earlier, but forgot to fix it. >6. Section 5 : "... and the UAC wants to send keep-alives=20 >towards the next hop, the entity MUST include a "keep" Via=20 >parameter in the SIP request". It should be "... the entity=20 >MUST include a "keep" parameter in the Via header it inserts=20 >into the SIP request". Correct. >7. Section 5 : "If the Via header header in the initial SIP=20 >responses contains a "keep" parameter with a "yes" value..."=20 >should read "If the top Via header in the 2xx SIP response=20 >contains a "keep" parameter with a "yes" value...". Correct. >8. Third paragraph of Section 5 : "If the initial SIP=20 >response contains a Flow-Timer header...". In the SIP=20 >outbound draft, the Flow-Timer header is only meant to be=20 >present in 'a successful registration response' (i.e. in a=20 >REGISTER response). I was thinking about the same. But, does outbound actaully forbid Flow-Timer to be used elsewhere than in REGISTER responses? I know that the procedures only talk about registration responses, but that is not the same thing. I guess what is missing from outbound is the normal table which shows for which methods and message types the header can be used. >9. Typos in Section 9.1 and 9.2 : "recommented" -> "recommended". I'll fix it. Thank you very much for your comments! Regards, Christer From christer.holmberg@ericsson.com Tue May 5 05:10:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233973A6949 for ; Tue, 5 May 2009 05:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.837 X-Spam-Level: X-Spam-Status: No, score=-5.837 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqWRbsAujIGK for ; Tue, 5 May 2009 05:10:24 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DA81E3A67B7 for ; Tue, 5 May 2009 05:10:23 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-5a-4a002d0355d3 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id EB.A4.19078.30D200A4; Tue, 5 May 2009 14:11:48 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 14:11:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CD7A.A95C5AA9" Date: Tue, 5 May 2009 14:11:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound: Flow-Timer only in REGISTER responses? Thread-Index: AcnNeqkOX5XuM32URKOjkWXFLR3y5Q== From: "Christer Holmberg" To: "SIPCORE" X-OriginalArrivalTime: 05 May 2009 12:11:47.0384 (UTC) FILETIME=[A9B75B80:01C9CD7A] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 12:10:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CD7A.A95C5AA9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One issue which was raised by Ya-Ching, when giving comments on the keep-draft, was whether it is allowed to use the Flow-Timer header in other messages than REGISTER responses? The keep draft also uses it in INVITEs when keep-alive is negotiated. The procedures in Outbound naturally only mention the Flow-Timer header in REGISTER responses, but it is nowever specifically indicated that the header is applicable for REGISTER responses only. What seems to be missing from Outbound is the table we normally use to define for which methods and message types a header is applicable. Example: Header field where proxy ACK BYE CAN INV OPT REG ------------------------------------------------------------------------ -------------------- Flow-Timer 18x - - - o - - Flow-Timer 2xx - - - o - o =20 Regards, Christer ------_=_NextPart_001_01C9CD7A.A95C5AA9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Outbound: Flow-Timer only in REGISTER responses?

Hi,

One issue which was raised by Ya-Ching, = when giving comments on the keep-draft, was whether it is allowed to use = the Flow-Timer header in other messages than REGISTER = responses?

The keep draft also uses it in INVITEs = when keep-alive is negotiated.

The procedures in Outbound naturally = only mention the Flow-Timer header in REGISTER responses, but it is = nowever specifically indicated that the header is applicable for = REGISTER responses only.

What seems to be missing from Outbound = is the table we normally use to define for which methods and message = types a header is applicable.

Example:

Header = field          = where   proxy ACK BYE CAN INV OPT REG
----------------------------------------------------------= ----------------------------------

Flow-Timer        =      = 18x           &nbs= p;    -      = -       -      = o     -       -
Flow-Timer        =      = 2xx           &nbs= p;    -      = -       -      = o     -       o  =


Regards,

Christer

------_=_NextPart_001_01C9CD7A.A95C5AA9-- From john.elwell@siemens-enterprise.com Tue May 5 06:52:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5493A6A2C for ; Tue, 5 May 2009 06:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjsjq0kG6zXC for ; Tue, 5 May 2009 06:52:08 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id DE6C83A686C for ; Tue, 5 May 2009 06:52:07 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJ60047LBX7OS@siemenscomms.co.uk> for sipcore@ietf.org; Tue, 05 May 2009 14:53:31 +0100 (BST) Date: Tue, 05 May 2009 14:53:13 +0100 From: "Elwell, John" In-reply-to: To: Christer Holmberg , "Tan, Ya Ching (NSN - DE/Munich)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:52:09 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 05 May 2009 13:04 > To: Tan, Ya Ching (NSN - DE/Munich) > Cc: SIPCORE > Subject: Re: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >=20 >=20 > >3. The draft repeatedly uses the term 'initial SIP request'. =20 > >What is the definition of this as it is not a known technical=20 > >term in SIP [RFC 3261]. The sentence in Section 5 "If the=20 > >UAC wishes to apply keep-alive for future calls, it MUST=20 > >insert a "keep" Via parameter in the initial SIP request of=20 > >those calls". This seems to imply that 'initial SIP request'=20 > >means the initial INVITE. 'Initial INVITE' is what RFC 3261=20 > >calls the dialog-initiating INVITE. Should the "keep"=20 > >parameter in Via only be used in initial REGISTER and=20 > initial INVITE ? >=20 > I think that is the current assumption, yes, but I am not sure whether > we need to make that restriction. >=20 > Regarding the usage of "initial SIP request", I guess it should say > "initial SIP dialog request", or something like that. I think similar > wording is used in some places of the document. [JRE] So the sender of an "initial SIP dialog request" would invoke the capability between itself and the next downstream SIP entity. Presumably a SIP proxy that does not record-route would never invoke this capability. But what about the next SIP entity downstream, if that doesn't record-route? Presumably it too should refrain from engaging in this capability. Mid-dialog requests would by-pass any non-record-routing proxies, so there would be no opportunity at the time of the "initial SIP dialog request" to create, and hence keep-alive, the connections needed for mid-dialog requests. I couldn't find any discussion of this in the latest draft. John From john.elwell@siemens-enterprise.com Tue May 5 07:07:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50523A6C38 for ; Tue, 5 May 2009 07:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTl09IWDs1dC for ; Tue, 5 May 2009 07:07:42 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 95BBB3A6AA8 for ; Tue, 5 May 2009 07:07:42 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJ60052BCKBN8@siemenscomms.co.uk> for sipcore@ietf.org; Tue, 05 May 2009 15:08:52 +0100 (BST) Date: Tue, 05 May 2009 15:08:26 +0100 From: "Elwell, John" In-reply-to: <9E895F3D-EE68-49E9-B262-034CFE035C15@softarmor.com> To: Dean Willis , Christer Holmberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001D8DFC4@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Long reply to: Target URI and History Info bis Thread-Index: AcnMfOXjWCLqh36qRCGe5LXL9kJNXgBDP9rQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> <9E895F3D-EE68-49E9-B262-034CFE035C15@softarmor.com> Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:07:43 -0000 Dean, I tend to agree with the use case that yourself and Paul articulated so well. Why did I agree to the H-I solution a few months back? Well, perhaps the use case was not properly articulated at the time, and it was difficult to see the wood for the trees. I seem to recall some freephone use case that some people wanted. I was quite happy with the Rosenberg loose route solution as a means of providing the last target AoR URI on the last hop, but when JDR stopped pursuing that approach, I accepted that H-I could do that too. However, when we start talking about H-I providing reliable information about earlier targets and expecting special behaviour to take place at the UAS based on this information (e.g., selecting a different mailbox) I get VERY nervous. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 04 May 2009 06:55 > To: Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] Long reply to: Target URI and History Info bis >=20 >=20 > On May 3, 2009, at 1:00 PM, Christer Holmberg wrote: >=20 > > > > Hi, > > > > I think the why-is-this-needed questions should have been=20 > asked when =20 > > we > > decided to start working on this in the first place. And, again, the > > different drafts that have been produced on this topic DO describe > > different use-cases. >=20 > I asked it then. I asked them as part of the process that=20 > lead to us =20 > chartering a deliverable of solving the problem. The reason I ask it =20 > again is that we seem to have forgotten the goal of the=20 > exercise, and =20 > be caught up in a solution without remembering the problem we were =20 > trying to solve. >=20 > SIP work has a history of doing this; it is a large part of why we =20 > have a fragmented and difficult to manage family of protocol =20 > specifications. >=20 > It bears asking again before we make things even worse. >=20 > Do we understand the implications of always delivering multiple H-I =20 > items, and do we understand how a UAS can figure out which=20 > H-I item or =20 > items represents the "correct" parameter set? >=20 > Because if we do NOT understand these things, then we have failed to =20 > meet our actual requirements. I'm not saying H-I doesn't meet the =20 > requirements; I'm asking the WG to 1) understand the=20 > requirements, and =20 > 2) verify that our proposed solution REALLY meets them. >=20 > Otherwise, we run the risk of producing yet another pointless =20 > mechanism that does not solve a problem that we failed to understand. >=20 >=20 > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From ietf.hanserik@gmail.com Tue May 5 07:57:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B5B3A689A for ; Tue, 5 May 2009 07:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXSszAkDcDgg for ; Tue, 5 May 2009 07:57:59 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 812543A6781 for ; Tue, 5 May 2009 07:57:58 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so729696fgb.18 for ; Tue, 05 May 2009 07:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=T3kRi+aDnBbC5d+QebuR1yJlGjmFyHrY187l457EzAc=; b=R1oFKOs6PiA3W0z4/vfli5hjKNQp5B9sF3TeXfVgXoqZYOnhBe46U9cYyN/9kDQA+3 P/q52WIb2FoKI4YUrCtMhSsxxG44aEJjI4wct3wq2NkwnSXNqBu/R3Dt6DlmoGGkDM/M VTuQ4iV/eVP2wlDrF8fLK9v0vTgK0d6L9qm2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qqhcxsRiiJ/LiIbZkecH5mefVqcxdDl40K4VR7QfDP+oCTMjO8gzCDkqDRbHwpKwrM KXkZPtPAr/WOqtgdGdKqwPhNmH9KK2AwvjxJf0bgJ0c6pPYIEI4Hlaa6ofIXuteDYkpg JxMShYYJ1hY86ECAK1OnfMXcihJQcV6r1elyc= Received: by 10.86.91.16 with SMTP id o16mr241470fgb.26.1241535561909; Tue, 05 May 2009 07:59:21 -0700 (PDT) Received: from ?192.168.2.100? (dslb-092-073-115-028.pools.arcor-ip.net [92.73.115.28]) by mx.google.com with ESMTPS id 12sm13260858fgg.20.2009.05.05.07.59.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 07:59:21 -0700 (PDT) Message-ID: <4A005448.7010201@gmail.com> Date: Tue, 05 May 2009 16:59:20 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Elwell, John" References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> <9E895F3D-EE68-49E9-B262-034CFE035C15@softarmor.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DFC4@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001D8DFC4@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:58:00 -0000 The following observation then must be comforting: There are no requirements to deliver "earlier targets". The target-uri work only requires the current target's uri information to be delivered. If the consequences of using H-I has some unnerving side-effects, well... its a little late to realise that. I am somewhat puzzled as to what proposal is being brought forward here. /Hans Erik Elwell, John wrote: > Dean, > > I tend to agree with the use case that yourself and Paul articulated so > well. Why did I agree to the H-I solution a few months back? Well, > perhaps the use case was not properly articulated at the time, and it > was difficult to see the wood for the trees. I seem to recall some > freephone use case that some people wanted. I was quite happy with the > Rosenberg loose route solution as a means of providing the last target > AoR URI on the last hop, but when JDR stopped pursuing that approach, I > accepted that H-I could do that too. However, when we start talking > about H-I providing reliable information about earlier targets and > expecting special behaviour to take place at the UAS based on this > information (e.g., selecting a different mailbox) I get VERY nervous. > > John > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis >> Sent: 04 May 2009 06:55 >> To: Christer Holmberg >> Cc: SIPCORE >> Subject: Re: [sipcore] Long reply to: Target URI and History Info bis >> >> >> On May 3, 2009, at 1:00 PM, Christer Holmberg wrote: >> >> >>> Hi, >>> >>> I think the why-is-this-needed questions should have been >>> >> asked when >> >>> we >>> decided to start working on this in the first place. And, again, the >>> different drafts that have been produced on this topic DO describe >>> different use-cases. >>> >> I asked it then. I asked them as part of the process that >> lead to us >> chartering a deliverable of solving the problem. The reason I ask it >> again is that we seem to have forgotten the goal of the >> exercise, and >> be caught up in a solution without remembering the problem we were >> trying to solve. >> >> SIP work has a history of doing this; it is a large part of why we >> have a fragmented and difficult to manage family of protocol >> specifications. >> >> It bears asking again before we make things even worse. >> >> Do we understand the implications of always delivering multiple H-I >> items, and do we understand how a UAS can figure out which >> H-I item or >> items represents the "correct" parameter set? >> >> Because if we do NOT understand these things, then we have failed to >> meet our actual requirements. I'm not saying H-I doesn't meet the >> requirements; I'm asking the WG to 1) understand the >> requirements, and >> 2) verify that our proposed solution REALLY meets them. >> >> Otherwise, we run the risk of producing yet another pointless >> mechanism that does not solve a problem that we failed to understand. >> >> >> -- >> Dean >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dean.willis@softarmor.com Tue May 5 09:37:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9A53A6BA7 for ; Tue, 5 May 2009 09:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6ODfClQ2OxV for ; Tue, 5 May 2009 09:37:23 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 070C83A7025 for ; Tue, 5 May 2009 09:36:18 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n45Gb8Z6032752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 May 2009 11:37:10 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <49FFA6BC.1060207@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 11:37:03 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> <49FFA6BC.1060207@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:37:23 -0000 On May 4, 2009, at 9:38 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: >> On May 4, 2009, at 3:11 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> I don't think there is an issue with Supported. Supported:foo >>> means "I >>> support foo" - nothing more, nothing less. >> I agree 100%. > > What about those cases where a UAC and UAS must both "support" it > for it to be used, but where the roles are asymmetric? What about them? Sending a "Supported" in a request or response means the UAC supports the extension. Sending a "Require" in a request means the UAS must support the extension. Whether or not the extension actually gets used is dependent on policy, authorization, and the extension itself. > > > There are lots of those. For instance, eventlist. Do you only > advertise support if you can *receive* an eventlist in a NOTIFY? Yes. > > > What do you say if you are capable of sending eventlist in a NOTIFY, > but not of receiving it. (Perhaps because you never subscribe to > anything.) Nothing (at least from the current spec, AFAIK). If we need asymmetric negotiation, we need to define two different option tags, for example "event-list-receive" and "eventlist-send". -- Dean From dean.willis@softarmor.com Tue May 5 09:39:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452DC3A6D4D for ; Tue, 5 May 2009 09:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ao9YoR1xwEN for ; Tue, 5 May 2009 09:39:10 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 69DE43A6945 for ; Tue, 5 May 2009 09:39:10 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n45GeWMg000342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 May 2009 11:40:34 -0500 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 11:40:27 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> <4732811D-A70A-4E6D-92D7-B44AD3BB3F2D@softarmor.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:39:11 -0000 On May 5, 2009, at 1:10 AM, Christer Holmberg wrote: >> > > Doesn't that mean that most extensions are badly written? Most of our documents could stand improvement. Perfection keeps eluding me. Please let me know when you feel you've achieved it, as I enjoy comedy. > > >>> And yes, we have erroneous RFCs. Just because we wrote it that way >>> doesn't make it right -- either something has to change in RFC 3261, >>> or something has to change in the RFCs that misuse Require. > > Some extensions are already widely deployed, so I don't think we can > do > very much about those. Other than fixing the specification, there's not much we can do. Backward compatibility can be assured through Postel's maxim. Specification fixes should explain how this applies to the specification in question. -- Dean From dean.willis@softarmor.com Tue May 5 09:45:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE5A3A70F8 for ; Tue, 5 May 2009 09:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWoXU+tNAfAy for ; Tue, 5 May 2009 09:45:02 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 833F03A7025 for ; Tue, 5 May 2009 09:45:02 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n45GkPqK000390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 May 2009 11:46:26 -0500 Message-Id: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 11:46:19 -0500 References: X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:45:03 -0000 On May 5, 2009, at 7:11 AM, Christer Holmberg wrote: > > Hi, > > One issue which was raised by Ya-Ching, when giving comments on the > keep-draft, was whether it is allowed to use the Flow-Timer header > in other messages than REGISTER responses? > > The keep draft also uses it in INVITEs when keep-alive is negotiated. > > The procedures in Outbound naturally only mention the Flow-Timer > header in REGISTER responses, but it is nowever specifically > indicated that the header is applicable for REGISTER responses only. > > What seems to be missing from Outbound is the table we normally use > to define for which methods and message types a header is applicable. > > Example: > > Header field where proxy ACK BYE CAN INV OPT REG > -------------------------------------------------------------------------------------------- > > Flow-Timer 18x - - - > o - - > Flow-Timer 2xx - - - > o - o > That's probably because that table is the source of more confusion, IMHO, than anything else in the entire SIP specification family. It direly needs a retrofit, although I'm not sure that such is really possible: we add another column to the table for each method-type extension, such as SUB, NOT, INF, etc. This raises the question: If a new request type is specified, is it up to that request-type to fix "the table" for every header field, or do we need to revise the RC for each extension so as to add the new column to their tables? Consequently, I greatly prefer to specify the behavior in text, using more general terms such as "requests" and "responses", which specific caveats around where such an extension header is meaningful, where it is forbidden, and where it is ignorable. -- Dean From dean.willis@softarmor.com Tue May 5 09:47:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C013A71A8 for ; Tue, 5 May 2009 09:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NDIW6Ya8b0z for ; Tue, 5 May 2009 09:47:51 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 28CFA3A71BD for ; Tue, 5 May 2009 09:46:44 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n45Gm4it000410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 May 2009 11:48:06 -0500 Message-Id: From: Dean Willis To: Hans Erik van Elburg In-Reply-To: <4A005448.7010201@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 11:47:58 -0500 References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> <9E895F3D-EE68-49E9-B262-034CFE035C15@softarmor.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DFC4@GBNTHT12009MSX.gb002.siemens.net> <4A005448.7010201@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:47:51 -0000 On May 5, 2009, at 9:59 AM, Hans Erik van Elburg wrote: > The following observation then must be comforting: There are no > requirements to deliver "earlier targets". The target-uri work only > requires the current target's uri information to be delivered. > > If the consequences of using H-I has some unnerving side-effects, > well... its a little late to realise that. > I am somewhat puzzled as to what proposal is being brought forward > here. It's not too late. We haven't died yet. We haven't even published an RFC, and that's far less final as we often revise RFCs by publishing new ones. -- Dean From AUDET@nortel.com Tue May 5 09:53:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE42F3A714A for ; Tue, 5 May 2009 09:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YzzhEbgr8gP for ; Tue, 5 May 2009 09:53:22 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8DC6C3A71A2 for ; Tue, 5 May 2009 09:53:22 -0700 (PDT) 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 n45Gsjm00008; Tue, 5 May 2009 16:54:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 11:53:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DD3F546@zrc2hxm0.corp.nortel.com> In-Reply-To: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Outbound: Flow-Timer only in REGISTER responses? Thread-Index: AcnNoVuGVK8N7SwbQuSGLdOHNHtW5QAACUVA References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Christer Holmberg" Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:53:23 -0000 In outbound, the following should be added: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ Flow-Timer 2xx a - - - - - o In Keep, the following:=20 Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ Flow-Timer 18x a - - - o - - Flow-Timer 2xx a - - - o - o > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > Sent: Tuesday, May 05, 2009 09:46 > To: Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER=20 > responses? >=20 >=20 > On May 5, 2009, at 7:11 AM, Christer Holmberg wrote: >=20 > > > > Hi, > > > > One issue which was raised by Ya-Ching, when giving comments on the=20 > > keep-draft, was whether it is allowed to use the Flow-Timer=20 > header in=20 > > other messages than REGISTER responses? > > > > The keep draft also uses it in INVITEs when keep-alive is=20 > negotiated. > > > > The procedures in Outbound naturally only mention the Flow-Timer=20 > > header in REGISTER responses, but it is nowever=20 > specifically indicated=20 > > that the header is applicable for REGISTER responses only. > > > > What seems to be missing from Outbound is the table we=20 > normally use to=20 > > define for which methods and message types a header is applicable. > > > > Example: > > > > Header field where proxy ACK BYE CAN INV OPT REG > >=20 > ---------------------------------------------------------------------- > > ---------------------- > > > > Flow-Timer 18x - - - =20 > > o - - > > Flow-Timer 2xx - - - =20 > > o - o > > > That's probably because that table is the source of more=20 > confusion, IMHO, than anything else in the entire SIP=20 > specification family. It direly needs a retrofit, although=20 > I'm not sure that such is really > possible: we add another column to the table for each=20 > method-type extension, such as SUB, NOT, INF, etc. This=20 > raises the question: If a new request type is specified, is=20 > it up to that request-type to fix "the table" for every=20 > header field, or do we need to revise the RC for each=20 > extension so as to add the new column to their tables? >=20 > Consequently, I greatly prefer to specify the behavior in=20 > text, using more general terms such as "requests" and=20 > "responses", which specific caveats around where such an=20 > extension header is meaningful, where it is forbidden, and=20 > where it is ignorable. >=20 > -- > Dean >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Tue May 5 10:28:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A903A718E for ; Tue, 5 May 2009 10:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.989 X-Spam-Level: X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGv0xwhPbhaU for ; Tue, 5 May 2009 10:28:23 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4D97A3A6CD1 for ; Tue, 5 May 2009 10:28:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,298,1238976000"; d="scan'208";a="43465196" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 May 2009 17:29:49 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n45HTnoe024091; Tue, 5 May 2009 13:29:49 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n45HThi7005537; Tue, 5 May 2009 17:29:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 13:29:48 -0400 Received: from [10.86.255.101] ([10.86.255.101]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 13:29:48 -0400 Message-ID: <4A00778A.6060707@cisco.com> Date: Tue, 05 May 2009 13:29:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> <49FFA6BC.1060207@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2009 17:29:48.0391 (UTC) FILETIME=[16E1F770:01C9CDA7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2227; t=1241544589; x=1242408589; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20 |To:=20Dean=20Willis=20; bh=rO1XNltfun6xaVzByLZq0HSAWq07Z9A0PIsfzfF8P1U=; b=pNi/tkZ0cEaudG2oYi6fCdgSMPU3WrcvlyiuvvI43ivQSnDn9Nysq8KQl/ O9KcDCatAOShWZXjd7CkQ5tPNGd7MHo5apJdaW7KtAmhwOqVL/4lkUhUKUOo LEjeGQ+7Mj; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:28:24 -0000 Dean Willis wrote: > > On May 4, 2009, at 9:38 PM, Paul Kyzivat wrote: > >> >> >> Dean Willis wrote: >>> On May 4, 2009, at 3:11 PM, Christer Holmberg wrote: >>>> >>>> Hi, >>>> >>>> I don't think there is an issue with Supported. Supported:foo means "I >>>> support foo" - nothing more, nothing less. >>> I agree 100%. >> >> What about those cases where a UAC and UAS must both "support" it for >> it to be used, but where the roles are asymmetric? > > What about them? Sending a "Supported" in a request or response means > the UAC supports the extension. Which role does it mean it supports? Assuming the asymmetric roles can be ascribed to the UAC and UAS, then perhaps a Supported:foo in a request means that the sender supports the UAC role for foo, and a Supported:foo in a response means that the sender supports the UAS role for foo? But what if I want to know if you support the UAC role for foo? How can I find that out? I could send you an OPTIONS request, but then your answer would be telling me if you support the UAS role, not the UAC role. > Sending a "Require" in a request means > the UAS must support the extension. Again, does that mean it must support the UAS role. What if I send a Require as part of a REFER in expectation that the option will be used in the referred request? In that case it will be the UAC role that it must use. > Whether or not the extension > actually gets used is dependent on policy, authorization, and the > extension itself. I agree that is the way it should have been. >> There are lots of those. For instance, eventlist. Do you only >> advertise support if you can *receive* an eventlist in a NOTIFY? > > Yes. > >> What do you say if you are capable of sending eventlist in a NOTIFY, >> but not of receiving it. (Perhaps because you never subscribe to >> anything.) > > Nothing (at least from the current spec, AFAIK). > > If we need asymmetric negotiation, we need to define two different > option tags, for example "event-list-receive" and "eventlist-send". I think many of the options are asymmetric, so perhaps many of them really need pairs of options. Thanks, Paul From dean.willis@softarmor.com Tue May 5 11:21:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28D73A69F8 for ; Tue, 5 May 2009 11:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-Q4j+Xs5-T6 for ; Tue, 5 May 2009 11:21:41 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D2CA23A7059 for ; Tue, 5 May 2009 11:20:45 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n45IM5o8001112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 May 2009 13:22:06 -0500 Message-Id: <6EDFAB4E-1972-4E37-9980-058477C5DC84@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4A00778A.6060707@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 13:22:00 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> <49FFA6BC.1060207@cisco.com> <4A00778A.6060707@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 18:21:42 -0000 On May 5, 2009, at 12:29 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: >> On May 4, 2009, at 9:38 PM, Paul Kyzivat wrote: >>> >>> >>> Dean Willis wrote: >>>> On May 4, 2009, at 3:11 PM, Christer Holmberg wrote: >>>>> >>>>> Hi, >>>>> >>>>> I don't think there is an issue with Supported. Supported:foo >>>>> means "I >>>>> support foo" - nothing more, nothing less. >>>> I agree 100%. >>> >>> What about those cases where a UAC and UAS must both "support" it >>> for it to be used, but where the roles are asymmetric? >> What about them? Sending a "Supported" in a request or response >> means the UAC supports the extension. > > Which role does it mean it supports? Assuming the asymmetric roles > can be ascribed to the UAC and UAS, then perhaps a Supported:foo in > a request means that the sender supports the UAC role for foo, and a > Supported:foo in a response means that the sender supports the UAS > role for foo? Whichever role the assigning RFC defines for the option tag. By default, this is a symmetric negotiation, unless the RFC says otherwise. > But what if I want to know if you support the UAC role for foo? How > can I find that out? I could send you an OPTIONS request, but then > your answer would be telling me if you support the UAS role, not the > UAC role. That depends on the RFC. Most if not all currently only define one role for negotiation. > > >> Sending a "Require" in a request means the UAS must support the >> extension. > > Again, does that mean it must support the UAS role. What if I send a > Require as part of a REFER in expectation that the option will be > used in the referred request? In that case it will be the UAC role > that it must use. Perhaps I should have said "the node that was acting as a UAS in the handling of the receipt of the request, even if it becomes a UAC in some future transaction wherein the extension applies". But sending a Require in the body of a REFER says very little or nothing about whether or not the extension will be applied in the transaction induced by the REFER; in general, if you want that to apply, you have to encode it as part of the Refer-To URI, because that's what gets applied to the induced request. Require in a body never really "induces" behavior. For example, you might Require me to support a feature that I support don't allow you to use. I don't fail the request with a 420 -- instead, I just ignore your Require. > > >> Whether or not the extension actually gets used is dependent on >> policy, authorization, and the extension itself. > > I agree that is the way it should have been. No, really it's that way. See the above example on not using an extension . . . It's just the the discussion in some of the RFCs is misleading or downright wrong. > > >>> There are lots of those. For instance, eventlist. Do you only >>> advertise support if you can *receive* an eventlist in a NOTIFY? >> Yes. >>> What do you say if you are capable of sending eventlist in a >>> NOTIFY, but not of receiving it. (Perhaps because you never >>> subscribe to anything.) >> Nothing (at least from the current spec, AFAIK). >> If we need asymmetric negotiation, we need to define two different >> option tags, for example "event-list-receive" and "eventlist-send". > > I think many of the options are asymmetric, so perhaps many of them > really need pairs of options. I agree with that conclusion. -- Dean Willis From john.elwell@siemens-enterprise.com Tue May 5 12:32:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF023A6D91 for ; Tue, 5 May 2009 12:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dW4FEn-qCrLu for ; Tue, 5 May 2009 12:32:09 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 317E03A6C8D for ; Tue, 5 May 2009 12:32:09 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJ60018GRNXMP@siemenscomms.co.uk> for sipcore@ietf.org; Tue, 05 May 2009 20:33:33 +0100 (BST) Date: Tue, 05 May 2009 20:33:25 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1DD3F546@zrc2hxm0.corp.nortel.com> To: Francois Audet , Dean Willis , Christer Holmberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001DE157C@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Outbound: Flow-Timer only in REGISTER responses? Thread-Index: AcnNoVuGVK8N7SwbQuSGLdOHNHtW5QAACUVAAAWn1WA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1DD3F546@zrc2hxm0.corp.nortel.com> Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 19:32:10 -0000 What about SUBSCRIBE and REFER requests and responses? John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > Sent: 05 May 2009 17:54 > To: Dean Willis; Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER=20 > responses? >=20 > In outbound, the following should be added: >=20 > Header field where proxy ACK BYE CAN INV OPT REG > ___________________________________________________________ > Flow-Timer 2xx a - - - - - o >=20 > In Keep, the following:=20 >=20 > Header field where proxy ACK BYE CAN INV OPT REG > ___________________________________________________________ > Flow-Timer 18x a - - - o - - > Flow-Timer 2xx a - - - o - o >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org=20 > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > > Sent: Tuesday, May 05, 2009 09:46 > > To: Christer Holmberg > > Cc: SIPCORE > > Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER=20 > > responses? > >=20 > >=20 > > On May 5, 2009, at 7:11 AM, Christer Holmberg wrote: > >=20 > > > > > > Hi, > > > > > > One issue which was raised by Ya-Ching, when giving=20 > comments on the=20 > > > keep-draft, was whether it is allowed to use the Flow-Timer=20 > > header in=20 > > > other messages than REGISTER responses? > > > > > > The keep draft also uses it in INVITEs when keep-alive is=20 > > negotiated. > > > > > > The procedures in Outbound naturally only mention the Flow-Timer=20 > > > header in REGISTER responses, but it is nowever=20 > > specifically indicated=20 > > > that the header is applicable for REGISTER responses only. > > > > > > What seems to be missing from Outbound is the table we=20 > > normally use to=20 > > > define for which methods and message types a header is applicable. > > > > > > Example: > > > > > > Header field where proxy ACK BYE CAN INV OPT REG > > >=20 > >=20 > ---------------------------------------------------------------------- > > > ---------------------- > > > > > > Flow-Timer 18x - - - =20 > > > o - - > > > Flow-Timer 2xx - - - =20 > > > o - o > > > > > That's probably because that table is the source of more=20 > > confusion, IMHO, than anything else in the entire SIP=20 > > specification family. It direly needs a retrofit, although=20 > > I'm not sure that such is really > > possible: we add another column to the table for each=20 > > method-type extension, such as SUB, NOT, INF, etc. This=20 > > raises the question: If a new request type is specified, is=20 > > it up to that request-type to fix "the table" for every=20 > > header field, or do we need to revise the RC for each=20 > > extension so as to add the new column to their tables? > >=20 > > Consequently, I greatly prefer to specify the behavior in=20 > > text, using more general terms such as "requests" and=20 > > "responses", which specific caveats around where such an=20 > > extension header is meaningful, where it is forbidden, and=20 > > where it is ignorable. > >=20 > > -- > > Dean > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From ietf.hanserik@gmail.com Tue May 5 13:19:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DF928C232 for ; Tue, 5 May 2009 13:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4q0XT0zQUHqQ for ; Tue, 5 May 2009 13:19:03 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 661FD28C1A2 for ; Tue, 5 May 2009 13:18:59 -0700 (PDT) Received: by fxm2 with SMTP id 2so4950522fxm.37 for ; Tue, 05 May 2009 13:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=V4gOFUbmp500d4vp2+UZOLMh1fGFvOd9iUdi1hJ0yF8=; b=T5p+NjdtKlYVclTqGcnlWEaU5za8TUJ5/ds7kWV9w/DebfoXEy56azuxXAvaNzNkFB X4glCnJp87xtd16X/opm587/Hk2H+n5eO2cPsfq8cGptMAEYrq5GfbeWzPFR+J4Hww+K GW8ZqWJIdsGeMkoE7A7K6ZlfftEpDcr+43pUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Xj72LnrDHL53tM9VZmv4WIHRqXSU0TMxexqCRm4bzAr8fcIeftfS1TH9kix/xvIjnd RdwW0dxSuqCYz6xPbSDOsubGTF6l3zdKxdKpdfawLsgCVCTMLd6RfHTL1wIz18U4KdgG NOdRytTSnuVfvUcU4J0pm6yoexn7/0wa3nQ14= Received: by 10.103.24.17 with SMTP id b17mr343436muj.112.1241554823883; Tue, 05 May 2009 13:20:23 -0700 (PDT) Received: from ?192.168.2.100? (dslb-092-073-118-057.pools.arcor-ip.net [92.73.118.57]) by mx.google.com with ESMTPS id t10sm4955muh.0.2009.05.05.13.20.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 13:20:23 -0700 (PDT) Message-ID: <4A009F86.3060201@gmail.com> Date: Tue, 05 May 2009 22:20:22 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> <9E895F3D-EE68-49E9-B262-034CFE035C15@softarmor.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DFC4@GBNTHT12009MSX.gb002.siemens.net> <4A005448.7010201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:19:03 -0000 Dean, Again, considering that the requirements in the target-uri draft is what we want to solve, what IS your proposed solution? BR, /Hans Erik Dean Willis wrote: > > On May 5, 2009, at 9:59 AM, Hans Erik van Elburg wrote: > >> The following observation then must be comforting: There are no >> requirements to deliver "earlier targets". The target-uri work only >> requires the current target's uri information to be delivered. >> >> If the consequences of using H-I has some unnerving side-effects, >> well... its a little late to realise that. >> I am somewhat puzzled as to what proposal is being brought forward here. > > It's not too late. We haven't died yet. We haven't even published an > RFC, and that's far less final as we often revise RFCs by publishing > new ones. > > -- > Dean > From christer.holmberg@ericsson.com Tue May 5 13:41:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324E43A68CD for ; Tue, 5 May 2009 13:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.839 X-Spam-Level: X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MC7iPWrDoA8 for ; Tue, 5 May 2009 13:41:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 924E83A6DAC for ; Tue, 5 May 2009 13:41:14 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-f9-4a00a4bfdd4c Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A6.D5.19078.FB4A00A4; Tue, 5 May 2009 22:42:39 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 22:42:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 22:42:38 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001DE157C@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Outbound: Flow-Timer only in REGISTER responses? Thread-Index: AcnNoVuGVK8N7SwbQuSGLdOHNHtW5QAACUVAAAWn1WAAAmwdcA== References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1DD3F546@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D001DE157C@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Francois Audet" , "Dean Willis" X-OriginalArrivalTime: 05 May 2009 20:42:39.0509 (UTC) FILETIME=[07CE7450:01C9CDC2] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:41:47 -0000 Hi,=20 >What about SUBSCRIBE and REFER requests and responses? I guess the mechanism could be useful also for SUB and REF dialogs. Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > Sent: 05 May 2009 17:54 > To: Dean Willis; Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER=20 > responses? >=20 > In outbound, the following should be added: >=20 > Header field where proxy ACK BYE CAN INV OPT REG > ___________________________________________________________ > Flow-Timer 2xx a - - - - - o >=20 > In Keep, the following:=20 >=20 > Header field where proxy ACK BYE CAN INV OPT REG > ___________________________________________________________ > Flow-Timer 18x a - - - o - - > Flow-Timer 2xx a - - - o - o >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > > Sent: Tuesday, May 05, 2009 09:46 > > To: Christer Holmberg > > Cc: SIPCORE > > Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER=20 > > responses? > >=20 > >=20 > > On May 5, 2009, at 7:11 AM, Christer Holmberg wrote: > >=20 > > > > > > Hi, > > > > > > One issue which was raised by Ya-Ching, when giving > comments on the > > > keep-draft, was whether it is allowed to use the Flow-Timer > > header in > > > other messages than REGISTER responses? > > > > > > The keep draft also uses it in INVITEs when keep-alive is > > negotiated. > > > > > > The procedures in Outbound naturally only mention the Flow-Timer=20 > > > header in REGISTER responses, but it is nowever > > specifically indicated > > > that the header is applicable for REGISTER responses only. > > > > > > What seems to be missing from Outbound is the table we > > normally use to > > > define for which methods and message types a header is applicable. > > > > > > Example: > > > > > > Header field where proxy ACK BYE CAN INV OPT REG > > >=20 > >=20 > ---------------------------------------------------------------------- > > > ---------------------- > > > > > > Flow-Timer 18x - - - =20 > > > o - - > > > Flow-Timer 2xx - - - =20 > > > o - o > > > > > That's probably because that table is the source of more confusion,=20 > > IMHO, than anything else in the entire SIP specification family. It=20 > > direly needs a retrofit, although I'm not sure that such is really > > possible: we add another column to the table for each method-type=20 > > extension, such as SUB, NOT, INF, etc. This raises the question: If=20 > > a new request type is specified, is it up to that request-type to=20 > > fix "the table" for every header field, or do we need to revise the=20 > > RC for each extension so as to add the new column to their tables? > >=20 > > Consequently, I greatly prefer to specify the behavior in text,=20 > > using more general terms such as "requests" and "responses", which=20 > > specific caveats around where such an extension header is=20 > > meaningful, where it is forbidden, and where it is ignorable. > >=20 > > -- > > Dean > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Tue May 5 13:43:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305EA3A6D91 for ; Tue, 5 May 2009 13:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWFys1akOOy5 for ; Tue, 5 May 2009 13:43:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F13FF3A6D6C for ; Tue, 5 May 2009 13:43:36 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-a6-4a00a54e850f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 38.E5.19078.E45A00A4; Tue, 5 May 2009 22:45:02 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 22:45: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 Date: Tue, 5 May 2009 22:45:01 +0200 Message-ID: In-Reply-To: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Outbound: Flow-Timer only in REGISTER responses? Thread-Index: AcnNsiZFC2VIh85pRK+KxIX73/f68QADn4BA References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 05 May 2009 20:45:02.0163 (UTC) FILETIME=[5CD5BA30:01C9CDC2] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:43:38 -0000 Hi,=20 >>One issue which was raised by Ya-Ching, when giving comments on the=20 >>keep-draft, was whether it is allowed to use the Flow-Timer header in=20 >>other messages than REGISTER responses? >> >>The keep draft also uses it in INVITEs when keep-alive is negotiated. >> >>The procedures in Outbound naturally only mention the Flow-Timer=20 >>header in REGISTER responses, but it is nowever specifically indicated >>that the header is applicable for REGISTER responses only. >> >>What seems to be missing from Outbound is the table we normally use to >>define for which methods and message types a header is applicable. >> >>Example: >> >>Header field where proxy ACK BYE CAN INV OPT REG >>---------------------------------------------------------------------- >>---------------------- >> >>Flow-Timer 18x - - - =20 >>o - - >>Flow-Timer 2xx - - - =20 >>o - o >> >That's probably because that table is the source of more confusion, IMHO, than anything else in the entire SIP specification family. It direly needs a retrofit, although I'm not sure that such is really >possible: we add another column to the table for each method-type extension, such as SUB, NOT, INF, etc. This raises the question: If a new request type is specified, is it up to that request-type to fix >"the table" for every header field, or do we need to revise the RC for each extension so as to add the new column to their tables? > >Consequently, I greatly prefer to specify the behavior in text, using more general terms such as "requests" and "responses", which specific caveats around where such an extension header is meaningful,=20 >where it is forbidden, and where it is ignorable. I think the table is clear. Maybe we could have a table on some website. Then it would be easy to update it every time new methods and/or headers are added. Regards, Christer From christer.holmberg@ericsson.com Tue May 5 13:48:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04B23A6BC7 for ; Tue, 5 May 2009 13:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.842 X-Spam-Level: X-Spam-Status: No, score=-5.842 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxoZwxKir6tf for ; Tue, 5 May 2009 13:48:20 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6D1D63A694E for ; Tue, 5 May 2009 13:48:19 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-9e-4a00a668ff91 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 19.CE.24713.866A00A4; Tue, 5 May 2009 22:49:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 22:49: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 22:49:43 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tA= References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 05 May 2009 20:49:44.0236 (UTC) FILETIME=[04F6A6C0:01C9CDC3] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:48:21 -0000 Hi John, You raise a good point. The draft should probably say that a SIP entity MUST record-route (unless the entity is an endpoint) if it is going to send and/or receive keep-alives. Regards, Christer -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Tuesday, May 05, 2009 4:53 PM To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) Cc: SIPCORE Subject: RE: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) =20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 05 May 2009 13:04 > To: Tan, Ya Ching (NSN - DE/Munich) > Cc: SIPCORE > Subject: Re: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >=20 >=20 > >3. The draft repeatedly uses the term 'initial SIP request'. =20 > >What is the definition of this as it is not a known technical term in > >SIP [RFC 3261]. The sentence in Section 5 "If the UAC wishes to=20 > >apply keep-alive for future calls, it MUST insert a "keep" Via=20 > >parameter in the initial SIP request of those calls". This seems to=20 > >imply that 'initial SIP request' > >means the initial INVITE. 'Initial INVITE' is what RFC 3261 calls=20 > >the dialog-initiating INVITE. Should the "keep" > >parameter in Via only be used in initial REGISTER and > initial INVITE ? >=20 > I think that is the current assumption, yes, but I am not sure whether > we need to make that restriction. >=20 > Regarding the usage of "initial SIP request", I guess it should say > "initial SIP dialog request", or something like that. I think similar > wording is used in some places of the document. [JRE] So the sender of an "initial SIP dialog request" would invoke the capability between itself and the next downstream SIP entity. Presumably a SIP proxy that does not record-route would never invoke this capability. But what about the next SIP entity downstream, if that doesn't record-route? Presumably it too should refrain from engaging in this capability. Mid-dialog requests would by-pass any non-record-routing proxies, so there would be no opportunity at the time of the "initial SIP dialog request" to create, and hence keep-alive, the connections needed for mid-dialog requests. I couldn't find any discussion of this in the latest draft. John From christer.holmberg@ericsson.com Tue May 5 14:25:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799643A6BAD for ; Tue, 5 May 2009 14:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.844 X-Spam-Level: X-Spam-Status: No, score=-5.844 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dnqfz8gWLCJZ for ; Tue, 5 May 2009 14:25:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4971D3A6B1C for ; Tue, 5 May 2009 14:25:29 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-03-4a00af1d7c3c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 66.CF.24713.D1FA00A4; Tue, 5 May 2009 23:26:53 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 23:26:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 23:26:52 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnNoDdaosKTye2BQDqz/dlezEPqJAAJ1k6A References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> <4732811D-A70A-4E6D-92D7-B44AD3BB3F2D@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 05 May 2009 21:26:52.0943 (UTC) FILETIME=[356059F0:01C9CDC8] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 21:25:31 -0000 Hi,=20 >>Doesn't that mean that most extensions are badly written? > >Most of our documents could stand improvement.=20 I couldn't agree more, but in this case you are talking about a rule which may NEVER have been used for our specifications. >Perfection keeps eluding me. Please let me know when you feel you've achieved it, as I enjoy comedy. There is no such thing as perfection in standards. >>>And yes, we have erroneous RFCs. Just because we wrote it that way=20 >>>doesn't make it right -- either something has to change in RFC 3261,=20 >>>or something has to change in the RFCs that misuse Require. >> >>Some extensions are already widely deployed, so I don't think we can=20 >>do very much about those. > >Other than fixing the specification, there's not much we can do. > >Backward compatibility can be assured through Postel's maxim. =20 >Specification fixes should explain how this applies to the specification in question. Yes. Regards, Christer From spencer@wonderhamster.org Tue May 5 15:03:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B7D3A6DD7 for ; Tue, 5 May 2009 15:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.936 X-Spam-Level: X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[AWL=-0.938, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNGKAFdS4fzI for ; Tue, 5 May 2009 15:03:20 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 1FA853A6D0F for ; Tue, 5 May 2009 15:03:20 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1M1Skj2fqZ-000cvF; Tue, 05 May 2009 18:04:45 -0400 Message-ID: <3C48B0E939D44B7AB45CB63CAB85EE55@china.huawei.com> From: "Spencer Dawkins" To: "Christer Holmberg" , "Dean Willis" References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> Date: Tue, 5 May 2009 17:04:22 -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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX199f6CB6rwpdYZ3nuMI1PzJt5JjU3Ha9F3IXIG Dp3lyYoiZyPRhGUHktx5AxceL/jHRsBmA0sV82XjTOO3Amv80o 8LOjG8OsMe4uTkNq5tBX6JL900w9eb8UEaA1X6R8eo= Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 22:03:21 -0000 I'm kind of in the middle here... > I think the table is clear. I think that conceptually it is, or should be, clear. Having it split over a large number of documents today makes it less clear :-( > Maybe we could have a table on some website. Then it would be easy to > update it every time new methods and/or headers are added. I think Dean's concern wasn't about the technology ("need more columns"), but about the review and approval process - if there's one table, and I create a new method or header, is it my job to fill in the entire table for the new row/column, or is it someone else's job (keeping in mind that I may not be the smartest person about everything that's in the table now - I might just be the smartest person about the method or header that I'm defining. If three of us define two rows and a column, how do we ensure that there's enough review for the new version of the table? Stuff like that, I think. Or Dean can correct me. Thanks, Spencer From dean.willis@softarmor.com Tue May 5 17:01:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5413A6EA4 for ; Tue, 5 May 2009 17:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcbOgeD-dIW5 for ; Tue, 5 May 2009 17:01:37 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 72FBA3A6EA3 for ; Tue, 5 May 2009 17:00:42 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n460208I002935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 May 2009 19:02:03 -0500 Message-Id: From: Dean Willis To: Hans Erik van Elburg In-Reply-To: <4A009F86.3060201@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 19:01:55 -0500 References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> <9E895F3D-EE68-49E9-B262-034CFE035C15@softarmor.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DFC4@GBNTHT12009MSX.gb002.siemens.net> <4A005448.7010201@gmail.com> <4A009F86.3060201@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 00:01:38 -0000 On May 5, 2009, at 3:20 PM, Hans Erik van Elburg wrote: > Dean, > > Again, considering that the requirements in the target-uri draft is > what we want to solve, what IS your proposed solution? >> I'm not proposing one at this time. What I AM proposing is that we thoroughly analyze the proposal to make sure that it a) meets the given requirements (as stated in the draft), and b) that the given requirements address both the chartered milestone requirements as written and the requirements as intended when we adopted that milestone. Let's see if I can formulate what I think the problem with draft- rosenberg-sip-target-uri-delivery-01 is: I'm suspecting that somewhere in the interaction between service- invocation and retargeting, we're losing the parameters. Example A: Let's say alice@example.com is calling bob@example.org. Alice wishes to include some parameters for Bob's UA application that are understood by all the user agents at example.org. Bob, however, has forwarded his calls to carol@example.org. Alice's parameters go in the original request-URI. 1) Bob's proxy retargets to Carol, pushing the original request-URI into History-Info with an istarget parameter, because Identity in the reverse direction would now be expected to show Carol. 2) The request reaches Carol's proxy, which adds yet another history info (without istarget) containing Carol's contact-uri. 3) The request reaches Carol's phone, which works back the stack to retrieve the first "istarget", which now contains Carol's AOR and no parameters. It accepts the call, but it has no parameters for the application, so the application fails. Also, since Carol is the "target" she thinks the call is for her, not for Bob (although ostensibly the To: still shows bob@example.org) One might argue that Carol's UA can backtrack and know that the "first target" was Bob, and could potentially retrieve the parameters for Bob. How would it know to do this? And if it did, consider: Example B: alice@example.com is calling bob@example.org. Alice wishes to include some parameters for Bob's UA application that are understood by all the user agents at example.org. Bob, however, has forwarded his calls to carol@example.org, and Bob's proxy is engaging "service invocation as per 4.5 of raft-rosenberg-sip-target-uri-delivery-01. Carol, however, has also forwarded her calls to david@example.org Alice's parameters go in the original request-URI. 1) Bob's proxy retargets to Carol, pushing the original request-URI into History-Info with an istarget parameter, because Identity in the reverse direction would now be expected to show Carol. I'm not sure whether Bob's proxy pushes the new service-invocation parameters into the "original" R-URI or not; I think it likely that it adds a second H- I "istarget" that has the modifed parameters. 2) The request reaches Carol's proxy, which adds yet another history info (with istarget) containing David's AOR. 3) The request reaches David's proxy, which contact-routes to David's phone and adds yet another H-I (without istarget) for david@davidscontact. 4) The request reaches David's phone, which works back the stack to retrieve the first "istarget", which now contains David's AOR and no parameters. It accepts the call, but it has no parameters for the application, so the application fails. So which H-I should David's UA backtrack to to collect the parameters? It isn't the first one (bob@example.org ), since Bob's proxy added some parameters. It's not the last one (carol@example.org ) either. So what does it do? -- Dean Willis From dean.willis@softarmor.com Tue May 5 17:02:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2BD3A6EBA for ; Tue, 5 May 2009 17:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD2U8sTLz3l4 for ; Tue, 5 May 2009 17:02:36 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 99EA73A63C9 for ; Tue, 5 May 2009 17:02:36 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4603x2m002959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 May 2009 19:04:01 -0500 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 19:03:54 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> <4732811D-A70A-4E6D-92D7-B44AD3BB3F2D@softarmor.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 00:02:37 -0000 On May 5, 2009, at 4:26 PM, Christer Holmberg wrote: > > Hi, > >>> Doesn't that mean that most extensions are badly written? >> >> Most of our documents could stand improvement. > > I couldn't agree more, but in this case you are talking about a rule > which may NEVER have been used for our specifications. Yet it is written that way in RFC 3261. So, where is the error? To achieve consistency, SOMETHING has to change. -- Dean From christer.holmberg@ericsson.com Tue May 5 23:01:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662BE3A6B5D for ; Tue, 5 May 2009 23:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDhfBKN8Csra for ; Tue, 5 May 2009 23:01:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B42C03A69E3 for ; Tue, 5 May 2009 23:01:17 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-5e-4a0128022757 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 8E.63.24713.208210A4; Wed, 6 May 2009 08:02:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 08:02:39 +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, 6 May 2009 08:02:38 +0200 Message-ID: In-Reply-To: <3C48B0E939D44B7AB45CB63CAB85EE55@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Outbound: Flow-Timer only in REGISTER responses? Thread-Index: AcnN0nXEhbv201laTCCvLQKfQF+rbQAPXFJQ References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> <3C48B0E939D44B7AB45CB63CAB85EE55@china.huawei.com> From: "Christer Holmberg" To: "Spencer Dawkins" , "Dean Willis" X-OriginalArrivalTime: 06 May 2009 06:02:39.0447 (UTC) FILETIME=[42EE1E70:01C9CE10] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 06:01:46 -0000 Hi,=20 >>I'm kind of in the middle here... >=20 >>I think the table is clear. >=20 >I think that conceptually it is, or should be, clear. Having=20 >it split over a large number of documents today makes it less=20 >clear :-( > >=20 >>Maybe we could have a table on some website. Then it would be easy to=20 >>update it every time new methods and/or headers are added. >=20 >I think Dean's concern wasn't about the technology ("need=20 >more columns"), but about the review and approval process -=20 >if there's one table, and I create a new method or header, is=20 >it my job to fill in the entire table for the new row/column,=20 >or is it someone else's job (keeping in mind that I may not=20 >be the smartest person about everything that's in the table=20 >now - I might just be the smartest person about the method or=20 >header that I'm defining. If three of us define two rows and=20 >a column, how do we ensure that there's enough review for the=20 >new version of the table? Like everything else related to your new method/header, whatever is to be added to the table is discussed and agreed upon among the interested parties. Regards, Christer From christer.holmberg@ericsson.com Tue May 5 23:02:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F7E3A6781 for ; Tue, 5 May 2009 23:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+R0Cyzt4ZOn for ; Tue, 5 May 2009 23:02:47 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AE6133A6814 for ; Tue, 5 May 2009 23:02:43 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-f8-4a0128599870 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 1A.EA.19078.958210A4; Wed, 6 May 2009 08:04:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 08:04:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 May 2009 08:04:08 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnN3ipyhE/LDdfBTHaTXMCUVtmtLQAMi3pg References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FEE53A.8020009@cisco.com> <9A729B22-E014-4551-BCC7-BD039B55FA8A@softarmor.com> <4732811D-A70A-4E6D-92D7-B44AD3BB3F2D@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 06 May 2009 06:04:09.0133 (UTC) FILETIME=[78631DD0:01C9CE10] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 06:02:53 -0000 >>>>Doesn't that mean that most extensions are badly written? >>> >>>Most of our documents could stand improvement. >> >>I couldn't agree more, but in this case you are talking about a rule=20 >>which may NEVER have been used for our specifications. >=20 >Yet it is written that way in RFC 3261. >=20 >So, where is the error? To achieve consistency, SOMETHING has=20 >to change. Yes, and in this case LOTS of stuff would have to be changed. There would be essential correction drafts to a number of specs :) Regards, Christer From ietf.hanserik@gmail.com Tue May 5 23:16:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861A73A687C for ; Tue, 5 May 2009 23:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KfUdygEhb2d for ; Tue, 5 May 2009 23:16:37 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 554833A6B15 for ; Tue, 5 May 2009 23:15:47 -0700 (PDT) Received: by fxm2 with SMTP id 2so5171601fxm.37 for ; Tue, 05 May 2009 23:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=kaZyIjnJvurAxviG3dWf23I9SWirjhK4WUVt+Trioqg=; b=N9RsUtl0VV7H9DpgpE98NxodEDywNLHswJ7qnaUMuArM4uUbo6Gklerx2TQ9OyhKQr AcyP0HCkHwJQ7QxZbFdUcqwtCk7JZoaoqnCHpmJHlkR33t3kYB/ocH/LaKcOTNJKC5gV tZHcG4Lf/2I77htBJ6Sc5ec3gqRznkCUjc65k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VMPO28WqLWZs8TdOvEhMJcZRe83Q6HXmeR3VWnLcxW86D39Aqf0XHbbhI9jTJxXzmL WGmAjOuPy5YD0COjANA+pxz9j5xlixSq3ZlZ3EHj23y11uWkpPcGZRwvFu+lemzzBdAL kcw9Fs2Nlz9cbmPMPivSydxbmotZ4FJRWTXts= Received: by 10.103.90.17 with SMTP id s17mr621063mul.103.1241590630079; Tue, 05 May 2009 23:17:10 -0700 (PDT) Received: from ?192.168.2.100? (dslb-092-072-083-060.pools.arcor-ip.net [92.72.83.60]) by mx.google.com with ESMTPS id y6sm18112723mug.40.2009.05.05.23.17.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 23:17:09 -0700 (PDT) Message-ID: <4A012B65.4080704@gmail.com> Date: Wed, 06 May 2009 08:17:09 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> <49FA50CD.1080406@softarmor.com> <9E895F3D-EE68-49E9-B262-034CFE035C15@softarmor.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DFC4@GBNTHT12009MSX.gb002.siemens.net> <4A005448.7010201@gmail.com> <4A009F86.3060201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 06:16:38 -0000 Analyzing requirements is always a good thing to do. Note that the parameters are only part of the problem. The loss of the URI is the actual problem, if the URI contains parameters then they are lost together with the URI. That is why I do not agree with rephrasing this to a URI parameter loss problem. The whole URI is lost. The parameters only do carry their intended meaning within the context of this URI. The problem I have with example A & B is that they assume that parameters which are intended for B, are also relevant for C or D. This requirement is not expressed in the target-uri draft, nor do i think that it is a valid requirement. The service invocation use case explicitly considers: "use of complex URIs to address services within the network rather than subscribers. " This shows that the scenario that you are testing the solution against is not the intended use case. Note that the solution currently outlined in the target-uri draft is not sufficient, as it does not solve the freephone use case. So yes it still needs some work. Best Regards, /Hans Erik Dean Willis wrote: > > On May 5, 2009, at 3:20 PM, Hans Erik van Elburg wrote: > >> Dean, >> >> Again, considering that the requirements in the target-uri draft is >> what we want to solve, what IS your proposed solution? >>> > > I'm not proposing one at this time. What I AM proposing is that we > thoroughly analyze the proposal to make sure that it a) meets the > given requirements (as stated in the draft), and b) that the given > requirements address both the chartered milestone requirements as > written and the requirements as intended when we adopted that milestone. > > Let's see if I can formulate what I think the problem with > draft-rosenberg-sip-target-uri-delivery-01 is: > > I'm suspecting that somewhere in the interaction between > service-invocation and retargeting, we're losing the parameters. > > Example A: > > Let's say alice@example.com is calling bob@example.org. Alice wishes > to include some parameters for Bob's UA application that are > understood by all the user agents at example.org. Bob, however, has > forwarded his calls to carol@example.org. > > Alice's parameters go in the original request-URI. > > 1) Bob's proxy retargets to Carol, pushing the original request-URI > into History-Info with an istarget parameter, because Identity in the > reverse direction would now be expected to show Carol. > > 2) The request reaches Carol's proxy, which adds yet another history > info (without istarget) containing Carol's contact-uri. > > 3) The request reaches Carol's phone, which works back the stack to > retrieve the first "istarget", which now contains Carol's AOR and no > parameters. It accepts the call, but it has no parameters for the > application, so the application fails. Also, since Carol is the > "target" she thinks the call is for her, not for Bob (although > ostensibly the To: still shows bob@example.org) > > > One might argue that Carol's UA can backtrack and know that the "first > target" was Bob, and could potentially retrieve the parameters for > Bob. How would it know to do this? > > And if it did, consider: > > Example B: > > alice@example.com is calling bob@example.org. Alice wishes to include > some parameters for Bob's UA application that are understood by all > the user agents at example.org. Bob, however, has forwarded his calls > to carol@example.org, and Bob's proxy is engaging "service invocation > as per 4.5 of raft-rosenberg-sip-target-uri-delivery-01. Carol, > however, has also forwarded her calls to david@example.org > > Alice's parameters go in the original request-URI. > > 1) Bob's proxy retargets to Carol, pushing the original request-URI > into History-Info with an istarget parameter, because Identity in the > reverse direction would now be expected to show Carol. I'm not sure > whether Bob's proxy pushes the new service-invocation parameters into > the "original" R-URI or not; I think it likely that it adds a second > H-I "istarget" that has the modifed parameters. > > 2) The request reaches Carol's proxy, which adds yet another history > info (with istarget) containing David's AOR. > > 3) The request reaches David's proxy, which contact-routes to David's > phone and adds yet another H-I (without istarget) for > david@davidscontact. > > 4) The request reaches David's phone, which works back the stack to > retrieve the first "istarget", which now contains David's AOR and no > parameters. It accepts the call, but it has no parameters for the > application, so the application fails. So which H-I should David's > UA backtrack to to collect the parameters? It isn't the first one > (bob@example.org), since Bob's proxy added some parameters. It's not > the last one (carol@example.org) either. So what does it do? > > -- > Dean Willis > > From john.elwell@siemens-enterprise.com Tue May 5 23:16:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9A23A6D7C for ; Tue, 5 May 2009 23:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+B9q6mWiMUb for ; Tue, 5 May 2009 23:16:51 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 6DEFF3A6D36 for ; Tue, 5 May 2009 23:16:36 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJ700G4OLI1GO@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 06 May 2009 07:18:01 +0100 (BST) Date: Wed, 06 May 2009 07:17:58 +0100 From: "Elwell, John" In-reply-to: To: Christer Holmberg , "Tan, Ya Ching (NSN - DE/Munich)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tAAE5hMsA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 06:16:52 -0000 Christer, That seems somewhat back-to-front. You don't record route (and hence determine the path of the dialog) just because you want to do keep-alives. You first decide whether you are to be on the path of a dialog, and then you should decide whether to do keep-alives with your neighbour. I guess where non-record-routing proxies are involved, this can be achieved only on the first mid-dialog request. However, for an INVITE-initiated dialog this might be the ACK request, but unfortunately that doesn't have a response, so it is not suitable. In some cases it would be an UPDATE or PRACK request during the early dialog. For a SUBSCRIBE- or REFER-initiated dialog it would be the first NOTIFY request. In extending the keep-alive principle to dialogs, we need to be very careful how we specify it. John > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 05 May 2009 21:50 > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > Cc: SIPCORE > Subject: RE: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >=20 >=20 > Hi John, >=20 > You raise a good point. The draft should probably say that a=20 > SIP entity > MUST record-route (unless the entity is an endpoint) if it is going to > send and/or receive keep-alives. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Tuesday, May 05, 2009 4:53 PM > To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) > Cc: SIPCORE > Subject: RE: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 > (wasRE:Document Adoption) >=20 > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 05 May 2009 13:04 > > To: Tan, Ya Ching (NSN - DE/Munich) > > Cc: SIPCORE > > Subject: Re: [sipcore] Draft submission:=20 > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > >=20 > >=20 > > >3. The draft repeatedly uses the term 'initial SIP request'. =20 > > >What is the definition of this as it is not a known=20 > technical term in >=20 > > >SIP [RFC 3261]. The sentence in Section 5 "If the UAC wishes to=20 > > >apply keep-alive for future calls, it MUST insert a "keep" Via=20 > > >parameter in the initial SIP request of those calls". =20 > This seems to=20 > > >imply that 'initial SIP request' > > >means the initial INVITE. 'Initial INVITE' is what RFC 3261 calls=20 > > >the dialog-initiating INVITE. Should the "keep" > > >parameter in Via only be used in initial REGISTER and > > initial INVITE ? > >=20 > > I think that is the current assumption, yes, but I am not=20 > sure whether > > we need to make that restriction. > >=20 > > Regarding the usage of "initial SIP request", I guess it should say > > "initial SIP dialog request", or something like that. I=20 > think similar > > wording is used in some places of the document. > [JRE] So the sender of an "initial SIP dialog request" would=20 > invoke the > capability between itself and the next downstream SIP entity.=20 > Presumably > a SIP proxy that does not record-route would never invoke this > capability. But what about the next SIP entity downstream, if that > doesn't record-route? Presumably it too should refrain from=20 > engaging in > this capability. Mid-dialog requests would by-pass any > non-record-routing proxies, so there would be no opportunity=20 > at the time > of the "initial SIP dialog request" to create, and hence=20 > keep-alive, the > connections needed for mid-dialog requests. I couldn't find any > discussion of this in the latest draft. >=20 > John >=20 >=20 From christer.holmberg@ericsson.com Tue May 5 23:41:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093B83A6A3F for ; Tue, 5 May 2009 23:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Smlj8DYCcz+u for ; Tue, 5 May 2009 23:41:50 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9BB1B3A6AE3 for ; Tue, 5 May 2009 23:41:49 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-93-4a013182c915 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 5D.E7.24713.281310A4; Wed, 6 May 2009 08:43:15 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 08:43:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 May 2009 08:43:13 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tAAE5hMsAABMgsA References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 06 May 2009 06:43:14.0651 (UTC) FILETIME=[EE6CC2B0:01C9CE15] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 06:41:51 -0000 Hi John, I think there are cases where you may record route because you want to do keep-alives. But, we don't need to argue about that. I guess your point is that we should allow the keep-alive negotiation also in mid-dialog request? Regards, Christer > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: 6. toukokuuta 2009 9:18 > To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) > Cc: SIPCORE > Subject: RE: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >=20 > Christer, >=20 > That seems somewhat back-to-front. You don't record route=20 > (and hence determine the path of the dialog) just because you=20 > want to do keep-alives. You first decide whether you are to=20 > be on the path of a dialog, and then you should decide=20 > whether to do keep-alives with your neighbour. I guess where=20 > non-record-routing proxies are involved, this can be achieved=20 > only on the first mid-dialog request. However, for an=20 > INVITE-initiated dialog this might be the ACK request, but=20 > unfortunately that doesn't have a response, so it is not=20 > suitable. In some cases it would be an UPDATE or PRACK=20 > request during the early dialog. For a > SUBSCRIBE- or REFER-initiated dialog it would be the first=20 > NOTIFY request. >=20 > In extending the keep-alive principle to dialogs, we need to=20 > be very careful how we specify it. >=20 > John >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 05 May 2009 21:50 > > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > > Cc: SIPCORE > > Subject: RE: [sipcore] Draft submission:=20 > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > >=20 > >=20 > > Hi John, > >=20 > > You raise a good point. The draft should probably say that a SIP=20 > > entity MUST record-route (unless the entity is an endpoint)=20 > if it is=20 > > going to send and/or receive keep-alives. > >=20 > > Regards, > >=20 > > Christer > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, May 05, 2009 4:53 PM > > To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) > > Cc: SIPCORE > > Subject: RE: [sipcore] Draft submission: draft-ietf-sipcore-keep-00=20 > > (wasRE:Document Adoption) > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > > Sent: 05 May 2009 13:04 > > > To: Tan, Ya Ching (NSN - DE/Munich) > > > Cc: SIPCORE > > > Subject: Re: [sipcore] Draft submission:=20 > > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > > >=20 > > >=20 > > > >3. The draft repeatedly uses the term 'initial SIP request'. =20 > > > >What is the definition of this as it is not a known > > technical term in > >=20 > > > >SIP [RFC 3261]. The sentence in Section 5 "If the UAC wishes to=20 > > > >apply keep-alive for future calls, it MUST insert a "keep" Via=20 > > > >parameter in the initial SIP request of those calls". > > This seems to > > > >imply that 'initial SIP request' > > > >means the initial INVITE. 'Initial INVITE' is what RFC=20 > 3261 calls=20 > > > >the dialog-initiating INVITE. Should the "keep" > > > >parameter in Via only be used in initial REGISTER and > > > initial INVITE ? > > >=20 > > > I think that is the current assumption, yes, but I am not > > sure whether > > > we need to make that restriction. > > >=20 > > > Regarding the usage of "initial SIP request", I guess it=20 > should say=20 > > > "initial SIP dialog request", or something like that. I > > think similar > > > wording is used in some places of the document. > > [JRE] So the sender of an "initial SIP dialog request" would invoke=20 > > the capability between itself and the next downstream SIP entity. > > Presumably > > a SIP proxy that does not record-route would never invoke this=20 > > capability. But what about the next SIP entity downstream, if that=20 > > doesn't record-route? Presumably it too should refrain from=20 > engaging=20 > > in this capability. Mid-dialog requests would by-pass any=20 > > non-record-routing proxies, so there would be no opportunity at the=20 > > time of the "initial SIP dialog request" to create, and hence=20 > > keep-alive, the connections needed for mid-dialog requests.=20 > I couldn't=20 > > find any discussion of this in the latest draft. > >=20 > > John > >=20 > >=20 >=20 From john.elwell@siemens-enterprise.com Wed May 6 00:26:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0213A68A4 for ; Wed, 6 May 2009 00:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk8+5QCIx-4r for ; Wed, 6 May 2009 00:26:37 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 231DF3A68C4 for ; Wed, 6 May 2009 00:26:18 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJ700L10OQ75O@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 06 May 2009 08:27:43 +0100 (BST) Date: Wed, 06 May 2009 08:27:41 +0100 From: "Elwell, John" In-reply-to: To: Christer Holmberg , "Tan, Ya Ching (NSN - DE/Munich)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001DE15D2@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tAAE5hMsAABMgsAAAEnoMA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 07:26:38 -0000 Christer, Using the mechanism on mid-dialog requests might be one of the consequences. Another consequence might be that non-record-routing proxies should not attempt to invoke keep-alive. Perhaps we might deliberately exclude the mechanism for use between two entities between which there was one or more non-record-routing proxy. I don't really know - I just know that there are some issues to do with non-record-routing proxies that don't arise in the sip-outbound case (because the UA and the outbound proxy always stay in on the path). I would like to see some discussion about the applicability of keep-alives to dialogs, before we jump in and propose a mechanism. John=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 06 May 2009 07:43 > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > Cc: SIPCORE > Subject: RE: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >=20 >=20 > Hi John, >=20 > I think there are cases where you may record route because you want to > do keep-alives. >=20 > But, we don't need to argue about that. I guess your point is that we > should allow the keep-alive negotiation also in mid-dialog request? >=20 > Regards, >=20 > Christer >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Sent: 6. toukokuuta 2009 9:18 > > To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) > > Cc: SIPCORE > > Subject: RE: [sipcore] Draft submission:=20 > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > >=20 > > Christer, > >=20 > > That seems somewhat back-to-front. You don't record route=20 > > (and hence determine the path of the dialog) just because you=20 > > want to do keep-alives. You first decide whether you are to=20 > > be on the path of a dialog, and then you should decide=20 > > whether to do keep-alives with your neighbour. I guess where=20 > > non-record-routing proxies are involved, this can be achieved=20 > > only on the first mid-dialog request. However, for an=20 > > INVITE-initiated dialog this might be the ACK request, but=20 > > unfortunately that doesn't have a response, so it is not=20 > > suitable. In some cases it would be an UPDATE or PRACK=20 > > request during the early dialog. For a > > SUBSCRIBE- or REFER-initiated dialog it would be the first=20 > > NOTIFY request. > >=20 > > In extending the keep-alive principle to dialogs, we need to=20 > > be very careful how we specify it. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: 05 May 2009 21:50 > > > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > > > Cc: SIPCORE > > > Subject: RE: [sipcore] Draft submission:=20 > > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > > >=20 > > >=20 > > > Hi John, > > >=20 > > > You raise a good point. The draft should probably say that a SIP=20 > > > entity MUST record-route (unless the entity is an endpoint)=20 > > if it is=20 > > > going to send and/or receive keep-alives. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Tuesday, May 05, 2009 4:53 PM > > > To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) > > > Cc: SIPCORE > > > Subject: RE: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00=20 > > > (wasRE:Document Adoption) > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > > > Sent: 05 May 2009 13:04 > > > > To: Tan, Ya Ching (NSN - DE/Munich) > > > > Cc: SIPCORE > > > > Subject: Re: [sipcore] Draft submission:=20 > > > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > > > >=20 > > > >=20 > > > > >3. The draft repeatedly uses the term 'initial SIP request'. =20 > > > > >What is the definition of this as it is not a known > > > technical term in > > >=20 > > > > >SIP [RFC 3261]. The sentence in Section 5 "If the UAC=20 > wishes to=20 > > > > >apply keep-alive for future calls, it MUST insert a "keep" Via=20 > > > > >parameter in the initial SIP request of those calls". > > > This seems to > > > > >imply that 'initial SIP request' > > > > >means the initial INVITE. 'Initial INVITE' is what RFC=20 > > 3261 calls=20 > > > > >the dialog-initiating INVITE. Should the "keep" > > > > >parameter in Via only be used in initial REGISTER and > > > > initial INVITE ? > > > >=20 > > > > I think that is the current assumption, yes, but I am not > > > sure whether > > > > we need to make that restriction. > > > >=20 > > > > Regarding the usage of "initial SIP request", I guess it=20 > > should say=20 > > > > "initial SIP dialog request", or something like that. I > > > think similar > > > > wording is used in some places of the document. > > > [JRE] So the sender of an "initial SIP dialog request"=20 > would invoke=20 > > > the capability between itself and the next downstream SIP entity. > > > Presumably > > > a SIP proxy that does not record-route would never invoke this=20 > > > capability. But what about the next SIP entity=20 > downstream, if that=20 > > > doesn't record-route? Presumably it too should refrain from=20 > > engaging=20 > > > in this capability. Mid-dialog requests would by-pass any=20 > > > non-record-routing proxies, so there would be no=20 > opportunity at the=20 > > > time of the "initial SIP dialog request" to create, and hence=20 > > > keep-alive, the connections needed for mid-dialog requests.=20 > > I couldn't=20 > > > find any discussion of this in the latest draft. > > >=20 > > > John > > >=20 > > >=20 > >=20 >=20 From christer.holmberg@ericsson.com Wed May 6 02:13:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B333A6B26 for ; Wed, 6 May 2009 02:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVnn+XNxJhJe for ; Wed, 6 May 2009 02:13:38 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D08EA3A6D54 for ; Wed, 6 May 2009 02:13:21 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-06-4a015221face Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 68.EC.24713.122510A4; Wed, 6 May 2009 11:02:25 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 10:58: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 Date: Wed, 6 May 2009 10:58:48 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001DE15D2@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tAAE5hMsAABMgsAAAEnoMAAAbpjoA== References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15D2@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 06 May 2009 08:58:49.0749 (UTC) FILETIME=[DF523450:01C9CE28] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 09:13:40 -0000 Hi,=20 >Using the mechanism on mid-dialog requests might be one of the consequences. Yes. >Another consequence might be that non-record-routing proxies should not attempt to invoke keep-alive. Yes. >Perhaps we might deliberately exclude the mechanism for use between two entities between which there was one or more non-record-routing proxy. I am not sure I understand. The keep-alives are always between two neighbour entities. If there are other proxies (no matter if they are record-routing or not) between the two entities, thoe two entities will not send keep-alives between each other. When a SIP entity receives a request, it only checks the TOPMOST Via if it contains "keep", so if some other proxy has added a Via header (without "keep") no keep-alives will be sent. Regards, Christer >I don't really know - I just know that there are some issues to do with >non-record-routing proxies that don't arise in the=20 >sip-outbound case (because the UA and the outbound proxy=20 >always stay in on the path). >=20 > I would like to see some discussion about the applicability=20 > of keep-alives to dialogs, before we jump in and propose a mechanism. >=20 > John=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 06 May 2009 07:43 > > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > > Cc: SIPCORE > > Subject: RE: [sipcore] Draft submission:=20 > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > >=20 > >=20 > > Hi John, > >=20 > > I think there are cases where you may record route because=20 > you want to=20 > > do keep-alives. > >=20 > > But, we don't need to argue about that. I guess your point=20 > is that we=20 > > should allow the keep-alive negotiation also in mid-dialog request? > >=20 > > Regards, > >=20 > > Christer > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: 6. toukokuuta 2009 9:18 > > > To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) > > > Cc: SIPCORE > > > Subject: RE: [sipcore] Draft submission:=20 > > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > > >=20 > > > Christer, > > >=20 > > > That seems somewhat back-to-front. You don't record route=20 > (and hence=20 > > > determine the path of the dialog) just because you want to do=20 > > > keep-alives. You first decide whether you are to be on=20 > the path of a=20 > > > dialog, and then you should decide whether to do keep-alives with=20 > > > your neighbour. I guess where non-record-routing proxies are=20 > > > involved, this can be achieved only on the first=20 > mid-dialog request.=20 > > > However, for an INVITE-initiated dialog this might be the ACK=20 > > > request, but unfortunately that doesn't have a response, so it is=20 > > > not suitable. In some cases it would be an UPDATE or=20 > PRACK request=20 > > > during the early dialog. For a > > > SUBSCRIBE- or REFER-initiated dialog it would be the first NOTIFY=20 > > > request. > > >=20 > > > In extending the keep-alive principle to dialogs, we need=20 > to be very=20 > > > careful how we specify it. > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: 05 May 2009 21:50 > > > > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > > > > Cc: SIPCORE > > > > Subject: RE: [sipcore] Draft submission:=20 > > > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > > > >=20 > > > >=20 > > > > Hi John, > > > >=20 > > > > You raise a good point. The draft should probably say=20 > that a SIP=20 > > > > entity MUST record-route (unless the entity is an endpoint) > > > if it is > > > > going to send and/or receive keep-alives. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Tuesday, May 05, 2009 4:53 PM > > > > To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) > > > > Cc: SIPCORE > > > > Subject: RE: [sipcore] Draft submission:=20 > > draft-ietf-sipcore-keep-00 > > > > (wasRE:Document Adoption) > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > Christer Holmberg > > > > > Sent: 05 May 2009 13:04 > > > > > To: Tan, Ya Ching (NSN - DE/Munich) > > > > > Cc: SIPCORE > > > > > Subject: Re: [sipcore] Draft submission:=20 > > > > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > > > > >=20 > > > > >=20 > > > > > >3. The draft repeatedly uses the term 'initial SIP=20 > request'. =20 > > > > > >What is the definition of this as it is not a known > > > > technical term in > > > >=20 > > > > > >SIP [RFC 3261]. The sentence in Section 5 "If the UAC > > wishes to > > > > > >apply keep-alive for future calls, it MUST insert a=20 > "keep" Via=20 > > > > > >parameter in the initial SIP request of those calls". > > > > This seems to > > > > > >imply that 'initial SIP request' > > > > > >means the initial INVITE. 'Initial INVITE' is what RFC > > > 3261 calls > > > > > >the dialog-initiating INVITE. Should the "keep" > > > > > >parameter in Via only be used in initial REGISTER and > > > > > initial INVITE ? > > > > >=20 > > > > > I think that is the current assumption, yes, but I am not > > > > sure whether > > > > > we need to make that restriction. > > > > >=20 > > > > > Regarding the usage of "initial SIP request", I guess it > > > should say > > > > > "initial SIP dialog request", or something like that. I > > > > think similar > > > > > wording is used in some places of the document. > > > > [JRE] So the sender of an "initial SIP dialog request"=20 > > would invoke > > > > the capability between itself and the next downstream=20 > SIP entity. > > > > Presumably > > > > a SIP proxy that does not record-route would never invoke this=20 > > > > capability. But what about the next SIP entity > > downstream, if that > > > > doesn't record-route? Presumably it too should refrain from > > > engaging > > > > in this capability. Mid-dialog requests would by-pass any=20 > > > > non-record-routing proxies, so there would be no > > opportunity at the > > > > time of the "initial SIP dialog request" to create, and hence=20 > > > > keep-alive, the connections needed for mid-dialog requests. > > > I couldn't > > > > find any discussion of this in the latest draft. > > > >=20 > > > > John > > > >=20 > > > >=20 > > >=20 > >=20 >=20 From john.elwell@siemens-enterprise.com Wed May 6 03:04:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E8F3A696B for ; Wed, 6 May 2009 03:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1vgGmMlmwly for ; Wed, 6 May 2009 03:04:27 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 94A483A6868 for ; Wed, 6 May 2009 03:04:27 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJ70078BW1SPS@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 06 May 2009 11:05:52 +0100 (BST) Date: Wed, 06 May 2009 11:05:50 +0100 From: "Elwell, John" In-reply-to: To: Christer Holmberg , "Tan, Ya Ching (NSN - DE/Munich)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001DE1785@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tAAE5hMsAABMgsAAAEnoMAAAbpjoAAD+C6g Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15D2@GBNTHT12009MSX.gb002.siemens.net> Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 10:04:28 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 06 May 2009 09:59 > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > Cc: SIPCORE > Subject: RE: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >=20 >=20 > Hi,=20 >=20 > >Using the mechanism on mid-dialog requests might be one of the > consequences. >=20 > Yes. >=20 > >Another consequence might be that non-record-routing proxies=20 > should not > attempt to invoke keep-alive. >=20 > Yes. >=20 > >Perhaps we might deliberately exclude the mechanism for use=20 > between two > entities between which there was one or more non-record-routing proxy. >=20 > I am not sure I understand. The keep-alives are always between two > neighbour entities. If there are other proxies (no matter if they are > record-routing or not) between the two entities, thoe two=20 > entities will > not send keep-alives between each other. When a SIP entity receives a > request, it only checks the TOPMOST Via if it contains "keep", so if > some other proxy has added a Via header (without "keep") no=20 > keep-alives > will be sent. [JRE] Suppose an INVITE request is routed: UA1 -> Proxy1 - >Proxy2 -> Proxy3 -> UA2 Suppose also that Proxy1 and Proxy3 record-route, but Proxy2 does not. There is no point in doing keep-alive between Proxy1 and Proxy2, or between Proxy2 and Proxy3. When the first mid-dialog request is sent, it will go directly from Proxy1 to Proxy3 or vice versa. My question was whether we want to allow the invocation of keep-alive on that hop (Proxy1 to Proxy3) or whether we want to exclude this? Bear in mind that the first mid-dialog request (excluding ACK) could occur some considerable time after the call is established (e.g., an UPDATE request when session timer expires), so the benefit of keep-alive would last only between that request and the final BYE request. For SUBSCRIBE- and REFER-initiated dialogs it is a little simpler, because there is always an immediate NOTIFY request to form the dialog. John >=20 From christer.holmberg@ericsson.com Wed May 6 05:38:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0F73A6F19 for ; Wed, 6 May 2009 05:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ylxmp6rcC2Ka for ; Wed, 6 May 2009 05:38:11 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B71DC3A6F2C for ; Wed, 6 May 2009 05:34:03 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-d1-4a01830059ac Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 04.4F.19078.003810A4; Wed, 6 May 2009 14:30:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 14:30: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 Date: Wed, 6 May 2009 14:30:43 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001DE1785@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tAAE5hMsAABMgsAAAEnoMAAAbpjoAAD+C6gAATyu1A= References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15D2@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1785@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 06 May 2009 12:30:45.0281 (UTC) FILETIME=[7A5E6910:01C9CE46] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 12:38:12 -0000 Hi,=20 >>>Perhaps we might deliberately exclude the mechanism for use >>>between two entities between which there was one or more=20 >>>non-record-routing proxy. >>=20 >>I am not sure I understand. The keep-alives are always between two=20 >>neighbour entities. If there are other proxies (no matter if they are=20 >>record-routing or not) between the two entities, thoe two entities=20 >>will not send keep-alives between each other. When a SIP entity=20 >>receives a request, it only checks the TOPMOST Via if it contains=20 >>"keep", so if some other proxy has added a Via header (without "keep") no keep-alives will be sent. >> >[JRE] Suppose an INVITE request is routed: > >UA1 -> Proxy1 - >Proxy2 -> Proxy3 -> UA2=20 > >Suppose also that Proxy1 and Proxy3 record-route, but Proxy2 does not. > >There is no point in doing keep-alive between Proxy1 and Proxy2, or between Proxy2 and Proxy3. Correct. So, in that case, if Proxy2 doesn't Record-Route, it should not insert "yes" in the Via received from Proxy1, and it should not insert "keep" in its Via sent towards Proxy3. >When the first mid-dialog request is sent, it will go directly from Proxy1 to Proxy3 or vice versa.=20 Correct. >My question was whether we want to allow the invocation of keep-alive on that hop (Proxy1 to Proxy3) or whether we want to exclude this?=20 Technically I see no harm in allowing sending keep-alives TO an entity which didn't record-route, eventhough I am not sure it is useful. However, I don't think it shall be possible to send keep-alives FROM an entity which didn't record-route. Because, that entity would not know when the registration, or the session, terminates, in order to stop sending keep-alives. >Bear in mind that the first mid-dialog request (excluding ACK)=20 >could occur some considerable time after the call is=20 >established (e.g., an UPDATE request when session timer=20 >expires), so the benefit of keep-alive would last only=20 >between that request and the final BYE request. Yes. But, I think that in many (most?) cases keep-alives will be sent between entities which are going to be in the signalling path anyway. For example, I think one of the most common use-case will be between a UA and an edge proxy. So, the UA inserts "keep" in the Via of the initial request, and the edge proxy will record-route and insert "yes". >For SUBSCRIBE- and REFER-initiated dialogs it is a little simpler, because there is always an immediate NOTIFY request to form the dialog. Yes. Regards, Christer From pkyzivat@cisco.com Wed May 6 06:22:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7213A6FE6 for ; Wed, 6 May 2009 06:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEVpTXevVSdm for ; Wed, 6 May 2009 06:22:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0D26328C313 for ; Wed, 6 May 2009 06:17:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,302,1238976000"; d="scan'208";a="74932976" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 06 May 2009 13:19:20 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n46DJLuo015975; Wed, 6 May 2009 09:19:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n46DJLSd000998; Wed, 6 May 2009 13:19:21 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 09:19:21 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 09:19:21 -0400 Message-ID: <4A018E59.6060502@cisco.com> Date: Wed, 06 May 2009 09:19:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2009 13:19:21.0258 (UTC) FILETIME=[446D30A0:01C9CE4D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3093; t=1241615961; x=1242479961; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Outbound=3A=20Flow-Timer=20 only=20in=20REGISTER=20responses? |Sender:=20 |To:=20Christer=20Holmberg=20; bh=ObukHeY61h94JVqxKnHx7O67lnZeOr2nZJwu9Y6T1/g=; b=wGMd5ABiXHR1AkOH+cU7Oq0S3xRX5N20k6yZ62ma+mCgNZN2kbgAWBDkV2 QBh8aYAoJPW5/F0IgE2ZgjjzBHglvK6yzKoLyYjFCKFdYlLL1zdndCyva/Vr JxyEbP3T56; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:22:52 -0000 I have never had a problem with the idea of capturing this info in a table of this sort. It isn't perfect (some nuances still require text descriptions) but still useful. What is a problem about the table is maintaining it as extensions are made. Some things add new rows, and other things add new columns. We don't have a mechanism for getting it all together. A web site might be useful, but we would need some way to maintain it normatively. This is similar to the kinds of registries that IANA keeps for us, but it is more complex than anything else I have seen them do. We could explore if they could maintain such a structure. But that would not obviate the RFCs that introduce changes from enumerating the impact of those changes on all previously defined rows and columns. Thanks, Paul Christer Holmberg wrote: > Hi, > >>> One issue which was raised by Ya-Ching, when giving comments on the >>> keep-draft, was whether it is allowed to use the Flow-Timer header in >>> other messages than REGISTER responses? >>> >>> The keep draft also uses it in INVITEs when keep-alive is negotiated. >>> >>> The procedures in Outbound naturally only mention the Flow-Timer >>> header in REGISTER responses, but it is nowever specifically indicated > >>> that the header is applicable for REGISTER responses only. >>> >>> What seems to be missing from Outbound is the table we normally use to > >>> define for which methods and message types a header is applicable. >>> >>> Example: >>> >>> Header field where proxy ACK BYE CAN INV OPT REG >>> ---------------------------------------------------------------------- >>> ---------------------- >>> >>> Flow-Timer 18x - - - >>> o - - >>> Flow-Timer 2xx - - - >>> o - o >>> >> That's probably because that table is the source of more confusion, > IMHO, than anything else in the entire SIP specification family. It > direly needs a retrofit, although I'm not sure that such is really >> possible: we add another column to the table for each method-type > extension, such as SUB, NOT, INF, etc. This raises the question: If a > new request type is specified, is it up to that request-type to fix >> "the table" for every header field, or do we need to revise the RC for > each extension so as to add the new column to their tables? >> Consequently, I greatly prefer to specify the behavior in text, using > more general terms such as "requests" and "responses", which specific > caveats around where such an extension header is meaningful, >> where it is forbidden, and where it is ignorable. > > I think the table is clear. > > Maybe we could have a table on some website. Then it would be easy to > update it every time new methods and/or headers are added. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Wed May 6 06:33:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6676E3A6EDA for ; Wed, 6 May 2009 06:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WH7ytVQEoTv for ; Wed, 6 May 2009 06:33:43 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2D5C03A6F2E for ; Wed, 6 May 2009 06:30:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,302,1238976000"; d="scan'208";a="35043900" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 06 May 2009 13:31:59 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n46DVxD5000658; Wed, 6 May 2009 06:31:59 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n46DVxER006774; Wed, 6 May 2009 13:31:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 09:31:59 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 09:31:58 -0400 Message-ID: <4A01914E.4030308@cisco.com> Date: Wed, 06 May 2009 09:31:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Spencer Dawkins References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> <3C48B0E939D44B7AB45CB63CAB85EE55@china.huawei.com> In-Reply-To: <3C48B0E939D44B7AB45CB63CAB85EE55@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2009 13:31:58.0740 (UTC) FILETIME=[07EBC540:01C9CE4F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1640; t=1241616719; x=1242480719; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Outbound=3A=20Flow-Timer=20 only=20in=20REGISTER=20responses? |Sender:=20; bh=QWvw9sm9UJrGoEY0ZvXNvrhhf0nM2eCHiBxMYZS+H0A=; b=dAdiKVwoc929WgPtzaz3QfauMjBoh2eRAxFMtgPGAPmeUUKNQcyPhdrCj4 dfqNFgSDtAVbtvYcEOW25wlFxw8kASO0WEXevT6PJGo3S2Nx43Vi4d1y2Qox 5tZingkZ/O; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:33:53 -0000 Spencer Dawkins wrote: > I'm kind of in the middle here... > >> I think the table is clear. > > I think that conceptually it is, or should be, clear. Having it split > over a large number of documents today makes it less clear :-( > >> Maybe we could have a table on some website. Then it would be easy to >> update it every time new methods and/or headers are added. > > I think Dean's concern wasn't about the technology ("need more > columns"), but about the review and approval process - if there's one > table, and I create a new method or header, is it my job to fill in the > entire table for the new row/column, or is it someone else's job > (keeping in mind that I may not be the smartest person about everything > that's in the table now - I might just be the smartest person about the > method or header that I'm defining. If three of us define two rows and a > column, how do we ensure that there's enough review for the new version > of the table? > > Stuff like that, I think. Or Dean can correct me. Those are valid concerns. But they are valid whether there is a table or not. If we expect text in the document to replace the table, then the text has to address the same concerns. There is no way out - the interaction of a new method with all headers and responses must be considered, and the interaction of a new header or response with all methods must be considered. Thanks, Paul > Thanks, > > Spencer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Wed May 6 06:48:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC24F3A6B3D for ; Wed, 6 May 2009 06:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqjBVBD4ToO1 for ; Wed, 6 May 2009 06:47:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AAAC43A68EF for ; Wed, 6 May 2009 06:46:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,302,1238976000"; d="scan'208";a="299364062" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 May 2009 13:48:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n46Dm6sx014243; Wed, 6 May 2009 06:48:06 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n46Dm5jQ022200; Wed, 6 May 2009 13:48:06 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 09:48:05 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 09:48:05 -0400 Message-ID: <4A019514.908@cisco.com> Date: Wed, 06 May 2009 09:48:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2009 13:48:05.0346 (UTC) FILETIME=[48102420:01C9CE51] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4954; t=1241617686; x=1242481686; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Draft=20submission=3A=20dra ft-ietf-sipcore-keep-00=09(wasRE=3ADocument=0A=20Adoption) |Sender:=20; bh=nNQc6oSHCpNkLqj9EKAqao0nuNtYXL7EdC/gveDo0bA=; b=PCDNqUQf9dNv8tL3tgbckTeRvF+Vjq8Iw4yAFNtzVGu5+9VRv0vCHUd5TM ey42jdM1q/qcv6ZsaaqPg2RTcGHjQdUipvvkJUwt/8THcxIl4c+nhOlE1L0v fxfpOpV7SR; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:48:06 -0000 Christer Holmberg wrote: > Hi John, > > I think there are cases where you may record route because you want to > do keep-alives. Christer - can you explain that. I agree with John that it seems backwards. What would be a use case where the decision the do keep alives comes first and the need to r-r in order to be present for those keep alives is secondary? Thanks, Paul > But, we don't need to argue about that. I guess your point is that we > should allow the keep-alive negotiation also in mid-dialog request? > > Regards, > > Christer > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: 6. toukokuuta 2009 9:18 >> To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) >> Cc: SIPCORE >> Subject: RE: [sipcore] Draft submission: >> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >> >> Christer, >> >> That seems somewhat back-to-front. You don't record route >> (and hence determine the path of the dialog) just because you >> want to do keep-alives. You first decide whether you are to >> be on the path of a dialog, and then you should decide >> whether to do keep-alives with your neighbour. I guess where >> non-record-routing proxies are involved, this can be achieved >> only on the first mid-dialog request. However, for an >> INVITE-initiated dialog this might be the ACK request, but >> unfortunately that doesn't have a response, so it is not >> suitable. In some cases it would be an UPDATE or PRACK >> request during the early dialog. For a >> SUBSCRIBE- or REFER-initiated dialog it would be the first >> NOTIFY request. >> >> In extending the keep-alive principle to dialogs, we need to >> be very careful how we specify it. >> >> John >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: 05 May 2009 21:50 >>> To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) >>> Cc: SIPCORE >>> Subject: RE: [sipcore] Draft submission: >>> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >>> >>> >>> Hi John, >>> >>> You raise a good point. The draft should probably say that a SIP >>> entity MUST record-route (unless the entity is an endpoint) >> if it is >>> going to send and/or receive keep-alives. >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Tuesday, May 05, 2009 4:53 PM >>> To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) >>> Cc: SIPCORE >>> Subject: RE: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 >>> (wasRE:Document Adoption) >>> >>> >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>>> Sent: 05 May 2009 13:04 >>>> To: Tan, Ya Ching (NSN - DE/Munich) >>>> Cc: SIPCORE >>>> Subject: Re: [sipcore] Draft submission: >>>> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >>>> >>>> >>>>> 3. The draft repeatedly uses the term 'initial SIP request'. >>>>> What is the definition of this as it is not a known >>> technical term in >>> >>>>> SIP [RFC 3261]. The sentence in Section 5 "If the UAC wishes to >>>>> apply keep-alive for future calls, it MUST insert a "keep" Via >>>>> parameter in the initial SIP request of those calls". >>> This seems to >>>>> imply that 'initial SIP request' >>>>> means the initial INVITE. 'Initial INVITE' is what RFC >> 3261 calls >>>>> the dialog-initiating INVITE. Should the "keep" >>>>> parameter in Via only be used in initial REGISTER and >>>> initial INVITE ? >>>> >>>> I think that is the current assumption, yes, but I am not >>> sure whether >>>> we need to make that restriction. >>>> >>>> Regarding the usage of "initial SIP request", I guess it >> should say >>>> "initial SIP dialog request", or something like that. I >>> think similar >>>> wording is used in some places of the document. >>> [JRE] So the sender of an "initial SIP dialog request" would invoke >>> the capability between itself and the next downstream SIP entity. >>> Presumably >>> a SIP proxy that does not record-route would never invoke this >>> capability. But what about the next SIP entity downstream, if that >>> doesn't record-route? Presumably it too should refrain from >> engaging >>> in this capability. Mid-dialog requests would by-pass any >>> non-record-routing proxies, so there would be no opportunity at the >>> time of the "initial SIP dialog request" to create, and hence >>> keep-alive, the connections needed for mid-dialog requests. >> I couldn't >>> find any discussion of this in the latest draft. >>> >>> John >>> >>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From spencer@wonderhamster.org Wed May 6 07:55:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 387003A6EC5 for ; Wed, 6 May 2009 07:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llI9sBecyen1 for ; Wed, 6 May 2009 07:55:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 2AD473A69BA for ; Wed, 6 May 2009 07:54:17 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1M1iX335vu-000cps; Wed, 06 May 2009 10:55:41 -0400 Message-ID: <50A49B000C514078A79D61D1AF93B52F@china.huawei.com> From: "Spencer Dawkins" To: "Paul Kyzivat" , "Christer Holmberg" References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> <4A018E59.6060502@cisco.com> Date: Wed, 6 May 2009 09:55: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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+pp1nWLOlLmPmrbKUqQw1VXWMPfj2mzTTOYK5 V6LHSJsTJSNWEIHKgJomuvIyF0DB7qtx5oruoAUqd6qFYas9Zl sgBAGPoog/JQB9VCm8droPeID7OMxQKu6/BgWh5t1Y= Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:55:50 -0000 I'm probably not being clear here. > What is a problem about the table is maintaining it as extensions are > made. Some things add new rows, and other things add new columns. We don't > have a mechanism for getting it all together. > > A web site might be useful, but we would need some way to maintain it > normatively. This is similar to the kinds of registries that IANA keeps > for us, but it is more complex than anything else I have seen them do. We > could explore if they could maintain such a structure. But that would not > obviate the RFCs that introduce changes from enumerating the impact of > those changes on all previously defined rows and columns. What I was saying was that we know how to write, and review, multiple extensions in parallel using Internet Drafts, but we don't actually have infrastructure in place to do this using a single table. We certainly COULD create this table as an IANA registry - but that's not what we have now. I think Paul and I are agreeing that this would involve a gatekeeper who is more involved, earlier in the process, with more authority to say "no", than IANA usually is today. This isn't a technical concern, it's a process concern. Thanks, Spencer From pkyzivat@cisco.com Wed May 6 10:29:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCC028C28C for ; Wed, 6 May 2009 10:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoEDVIxazC7C for ; Wed, 6 May 2009 10:29:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 513DF28C29E for ; Wed, 6 May 2009 10:22:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,303,1238976000"; d="scan'208";a="181755338" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 06 May 2009 17:24:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n46HOFMJ017856; Wed, 6 May 2009 10:24:15 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n46HOENf010000; Wed, 6 May 2009 17:24:15 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 13:24:05 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 13:24:04 -0400 Message-ID: <4A01C7B4.3050605@cisco.com> Date: Wed, 06 May 2009 13:24:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Spencer Dawkins References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> <4A018E59.6060502@cisco.com> <50A49B000C514078A79D61D1AF93B52F@china.huawei.com> In-Reply-To: <50A49B000C514078A79D61D1AF93B52F@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2009 17:24:04.0826 (UTC) FILETIME=[7483DBA0:01C9CE6F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1733; t=1241630655; x=1242494655; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Outbound=3A=20Flow-Timer=20 only=20in=20REGISTER=20responses? |Sender:=20; bh=d1b3HwE+6d5aZ/XbiudOc6oR+5JxZFNpc5pmftyQDts=; b=JfnTkEEd+w8E9eNWijg/fyaAjjd39SeV98NNCQCQllj3q+EJvuFQY3WL26 diZI0XQMBWIZfqjYyioZIEj6thygicA9FY26278BR1upsF2HFEmpG6TXg7w5 lCLBxJ/qUe; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 17:29:26 -0000 Spencer, I agree with you, but I'm saying a bit more: Whether we have the table or not, the need for the gatekeeping is there. Trying to keep the table straight just *exposes* the need more clearly. When new message types, headers, or return codes are defined, the info equivalent to updating the table is needed, whether in the form of a table update or not. Thanks, Paul Spencer Dawkins wrote: > I'm probably not being clear here. > >> What is a problem about the table is maintaining it as extensions are >> made. Some things add new rows, and other things add new columns. We >> don't have a mechanism for getting it all together. >> >> A web site might be useful, but we would need some way to maintain it >> normatively. This is similar to the kinds of registries that IANA >> keeps for us, but it is more complex than anything else I have seen >> them do. We could explore if they could maintain such a structure. But >> that would not obviate the RFCs that introduce changes from >> enumerating the impact of those changes on all previously defined rows >> and columns. > > What I was saying was that we know how to write, and review, multiple > extensions in parallel using Internet Drafts, but we don't actually have > infrastructure in place to do this using a single table. > > We certainly COULD create this table as an IANA registry - but that's > not what we have now. > > I think Paul and I are agreeing that this would involve a gatekeeper who > is more involved, earlier in the process, with more authority to say > "no", than IANA usually is today. > > This isn't a technical concern, it's a process concern. > > Thanks, > > Spencer > > From christer.holmberg@ericsson.com Wed May 6 11:27:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7E928C1E3 for ; Wed, 6 May 2009 11:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+c5ERpb6FFQ for ; Wed, 6 May 2009 11:26:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8AD3A3A6C79 for ; Wed, 6 May 2009 11:19:03 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-6b-4a01d4ed0045 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id C2.C1.24713.DE4D10A4; Wed, 6 May 2009 20:20:29 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 20:20:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 May 2009 20:20:28 +0200 Message-ID: In-Reply-To: <4A019514.908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnOUUzMdyU1+ei7Sc2nVTf5jQA9kQAJM8Yg References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <4A019514.908@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 06 May 2009 18:20:29.0305 (UTC) FILETIME=[55D25E90:01C9CE77] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 18:27:03 -0000 Hi,=20 >>I think there are cases where you may record route because you want to do keep-alives. > >Christer - can you explain that. I agree with John that it seems backwards. What would be a use case where the decision the do keep alives comes first and the need to r-r in order to be present for those=20 >keep alives is secondary? I am not sure I understand what is meant by "first and secondary". My point is that an entity can choose to Record-Route because it wants to either send or receive keep-alives (in the same way that it may choose to record-record due to whatever other reasons). An edge proxy, if it detects that the UA is behind a NAT, could Record-Route in order to allow the UA to send keep-alives towards it. But, of course, we can allow an entity to indicate that it is willing to receive keep-alives (by inserting a "yes" value) even if it doesn't record-route. Regards, Christer > But, we don't need to argue about that. I guess your point is that we=20 > should allow the keep-alive negotiation also in mid-dialog request? >=20 > Regards, >=20 > Christer >=20 >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: 6. toukokuuta 2009 9:18 >> To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) >> Cc: SIPCORE >> Subject: RE: [sipcore] Draft submission:=20 >> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >> >> Christer, >> >> That seems somewhat back-to-front. You don't record route (and hence=20 >> determine the path of the dialog) just because you want to do=20 >> keep-alives. You first decide whether you are to be on the path of a=20 >> dialog, and then you should decide whether to do keep-alives with=20 >> your neighbour. I guess where non-record-routing proxies are=20 >> involved, this can be achieved only on the first mid-dialog request.=20 >> However, for an INVITE-initiated dialog this might be the ACK=20 >> request, but unfortunately that doesn't have a response, so it is not >> suitable. In some cases it would be an UPDATE or PRACK request during >> the early dialog. For a >> SUBSCRIBE- or REFER-initiated dialog it would be the first NOTIFY=20 >> request. >> >> In extending the keep-alive principle to dialogs, we need to be very=20 >> careful how we specify it. >> >> John >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: 05 May 2009 21:50 >>> To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) >>> Cc: SIPCORE >>> Subject: RE: [sipcore] Draft submission:=20 >>> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >>> >>> >>> Hi John, >>> >>> You raise a good point. The draft should probably say that a SIP=20 >>> entity MUST record-route (unless the entity is an endpoint) >> if it is >>> going to send and/or receive keep-alives. >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Tuesday, May 05, 2009 4:53 PM >>> To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) >>> Cc: SIPCORE >>> Subject: RE: [sipcore] Draft submission: draft-ietf-sipcore-keep-00=20 >>> (wasRE:Document Adoption) >>> >>> =20 >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>>> Sent: 05 May 2009 13:04 >>>> To: Tan, Ya Ching (NSN - DE/Munich) >>>> Cc: SIPCORE >>>> Subject: Re: [sipcore] Draft submission:=20 >>>> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >>>> >>>> >>>>> 3. The draft repeatedly uses the term 'initial SIP request'. =20 >>>>> What is the definition of this as it is not a known >>> technical term in >>> >>>>> SIP [RFC 3261]. The sentence in Section 5 "If the UAC wishes to=20 >>>>> apply keep-alive for future calls, it MUST insert a "keep" Via=20 >>>>> parameter in the initial SIP request of those calls". >>> This seems to >>>>> imply that 'initial SIP request' >>>>> means the initial INVITE. 'Initial INVITE' is what RFC >> 3261 calls >>>>> the dialog-initiating INVITE. Should the "keep" >>>>> parameter in Via only be used in initial REGISTER and >>>> initial INVITE ? >>>> >>>> I think that is the current assumption, yes, but I am not >>> sure whether >>>> we need to make that restriction. >>>> >>>> Regarding the usage of "initial SIP request", I guess it >> should say >>>> "initial SIP dialog request", or something like that. I >>> think similar >>>> wording is used in some places of the document. >>> [JRE] So the sender of an "initial SIP dialog request" would invoke=20 >>> the capability between itself and the next downstream SIP entity. >>> Presumably >>> a SIP proxy that does not record-route would never invoke this=20 >>> capability. But what about the next SIP entity downstream, if that=20 >>> doesn't record-route? Presumably it too should refrain from >> engaging >>> in this capability. Mid-dialog requests would by-pass any=20 >>> non-record-routing proxies, so there would be no opportunity at the=20 >>> time of the "initial SIP dialog request" to create, and hence=20 >>> keep-alive, the connections needed for mid-dialog requests. >> I couldn't >>> find any discussion of this in the latest draft. >>> >>> John >>> >>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From spencer@wonderhamster.org Wed May 6 11:37:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACA028C24B for ; Wed, 6 May 2009 11:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjhqsXdqNNmT for ; Wed, 6 May 2009 11:37:26 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 80A393A6F70 for ; Wed, 6 May 2009 11:28:12 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1M1ls80DBj-000chl; Wed, 06 May 2009 14:29:39 -0400 Message-ID: From: "Spencer Dawkins" To: "Paul Kyzivat" References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> <4A018E59.6060502@cisco.com> <50A49B000C514078A79D61D1AF93B52F@china.huawei.com> <4A01C7B4.3050605@cisco.com> Date: Wed, 6 May 2009 13:29:15 -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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX198OzL2KcZ5aXEHENKIQHLhSLI9eDmwBiL0cpt iP7JwRA7d9mUwhRLny2aEXbPYKbk+pIw5Wqhf1M4YrHgz7z6IE Nv6ILyYUC7iaoq7o49xAmmJW9ES516d1ucL0OxmkT0= Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 18:37:26 -0000 We agree on the bit more as well. Thanks, Spencer > Spencer, > > I agree with you, but I'm saying a bit more: > > Whether we have the table or not, the need for the gatekeeping is there. > Trying to keep the table straight just *exposes* the need more clearly. > When new message types, headers, or return codes are defined, the info > equivalent to updating the table is needed, whether in the form of a > table update or not. > > Thanks, > Paul From dean.willis@softarmor.com Wed May 6 11:43:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908A83A6841 for ; Wed, 6 May 2009 11:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiu-mJ-hT+Qy for ; Wed, 6 May 2009 11:43:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1F21028C202 for ; Wed, 6 May 2009 11:36:20 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-235-115.tx.res.rr.com [76.182.235.115]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n46Ibfx2009612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 May 2009 13:37:43 -0500 Message-Id: <158210ED-C655-42BB-8722-C747A31100E1@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4A01914E.4030308@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 6 May 2009 13:37:35 -0500 References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> <3C48B0E939D44B7AB45CB63CAB85EE55@china.huawei.com> <4A01914E.4030308@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 18:43:45 -0000 On May 6, 2009, at 8:31 AM, Paul Kyzivat wrote: > > > Spencer Dawkins wrote: >> I'm kind of in the middle here... >>> I think the table is clear. >> I think that conceptually it is, or should be, clear. Having it >> split over a large number of documents today makes it less clear :-( >>> Maybe we could have a table on some website. Then it would be easy >>> to >>> update it every time new methods and/or headers are added. >> I think Dean's concern wasn't about the technology ("need more >> columns"), but about the review and approval process - if there's >> one table, and I create a new method or header, is it my job to >> fill in the entire table for the new row/column, or is it someone >> else's job (keeping in mind that I may not be the smartest person >> about everything that's in the table now - I might just be the >> smartest person about the method or header that I'm defining. If >> three of us define two rows and a column, how do we ensure that >> there's enough review for the new version of the table? >> Stuff like that, I think. Or Dean can correct me. > > Those are valid concerns. But they are valid whether there is a > table or not. If we expect text in the document to replace the > table, then the text has to address the same concerns. I agree. > > > There is no way out - the interaction of a new method with all > headers and responses must be considered, and the interaction of a > new header or response with all methods must be considered. > Although strictly from a documentation procedure: the current format wouldn't allow enough columns to appear in an internet-draft format to actually allow a new RFC to properly updated the table. Plus, there are a lot of "conditionals" encoded in the table as additional row comments. I'm pretty sure that this confuses a lot of people -- I know it confuses me. Of course, it would help if we didn't keep defining special cases of application-affecting-transport logic like weird responses codes that Change the Rules. Perhaps some sort of formal language construct could express the logic in some sort of fsm-verifiable way? -- Dean From christer.holmberg@ericsson.com Wed May 6 12:04:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B4C3A6F5F for ; Wed, 6 May 2009 12:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.856 X-Spam-Level: X-Spam-Status: No, score=-5.856 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tt7Ry9jem+vJ for ; Wed, 6 May 2009 12:04:20 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 83A9C3A7077 for ; Wed, 6 May 2009 11:54:51 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-d3-4a01dd5026f9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id DD.4D.19078.05DD10A4; Wed, 6 May 2009 20:56:16 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 20:56:16 +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, 6 May 2009 20:56:15 +0200 Message-ID: In-Reply-To: <158210ED-C655-42BB-8722-C747A31100E1@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Outbound: Flow-Timer only in REGISTER responses? Thread-Index: AcnOecHX6qeuxzkTQg+rbGtn8VJxaQAAkzlA References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> <3C48B0E939D44B7AB45CB63CAB85EE55@china.huawei.com> <4A01914E.4030308@cisco.com> <158210ED-C655-42BB-8722-C747A31100E1@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , "Paul Kyzivat" X-OriginalArrivalTime: 06 May 2009 18:56:16.0551 (UTC) FILETIME=[55AE1B70:01C9CE7C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 19:04:21 -0000 >>There is no way out - the interaction of a new method with all headers >>and responses must be considered, and the interaction of a new header=20 >>or response with all methods must be considered. > > >Although strictly from a documentation procedure: the current format wouldn't allow enough columns to appear in an internet-draft format to actually allow a new RFC to properly updated the table. > >Plus, there are a lot of "conditionals" encoded in the table as additional row comments. I'm pretty sure that this confuses a lot of people -- I know it confuses me. Of course, it would help if we didn't=20 >keep defining special cases of application-affecting-transport logic like weird responses codes that Change the Rules. > >Perhaps some sort of formal language construct could express the logic in some sort of fsm-verifiable way? I guess we could start using the same mechanism as in 3GPP TS 24.229 Annex A. I am sure Keith would be more and happy to teach us :) Regards, Christer From john.elwell@siemens-enterprise.com Wed May 6 12:23:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642B13A6FAF for ; Wed, 6 May 2009 12:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcZUyOW17eRT for ; Wed, 6 May 2009 12:23:10 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 68C333A7247 for ; Wed, 6 May 2009 12:10:56 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJ800FADLCMXD@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 06 May 2009 20:12:22 +0100 (BST) Date: Wed, 06 May 2009 20:12:21 +0100 From: "Elwell, John" In-reply-to: To: Christer Holmberg , "Tan, Ya Ching (NSN - DE/Munich)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001DE1AD4@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tAAE5hMsAABMgsAAAEnoMAAAbpjoAAD+C6gAATyu1AAAnYTQA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15D2@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1785@GBNTHT12009MSX.gb002.siemens.net> Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 19:23:11 -0000 Christer,=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 06 May 2009 13:31 > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > Cc: SIPCORE > Subject: RE: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >=20 >=20 > Hi,=20 >=20 > >>>Perhaps we might deliberately exclude the mechanism for use > >>>between two entities between which there was one or more=20 > >>>non-record-routing proxy. > >>=20 > >>I am not sure I understand. The keep-alives are always between two=20 > >>neighbour entities. If there are other proxies (no matter=20 > if they are=20 > >>record-routing or not) between the two entities, thoe two entities=20 > >>will not send keep-alives between each other. When a SIP entity=20 > >>receives a request, it only checks the TOPMOST Via if it contains=20 > >>"keep", so if some other proxy has added a Via header=20 > (without "keep") > no keep-alives will be sent. > >> > >[JRE] Suppose an INVITE request is routed: > > > >UA1 -> Proxy1 - >Proxy2 -> Proxy3 -> UA2=20 > > > >Suppose also that Proxy1 and Proxy3 record-route, but Proxy2=20 > does not. > > > >There is no point in doing keep-alive between Proxy1 and Proxy2, or > between Proxy2 and Proxy3. >=20 > Correct. So, in that case, if Proxy2 doesn't Record-Route, it=20 > should not > insert "yes" in the Via received from Proxy1, and it should not insert > "keep" in its Via sent towards Proxy3. >=20 >=20 > >When the first mid-dialog request is sent, it will go directly from > Proxy1 to Proxy3 or vice versa.=20 >=20 > Correct. >=20 >=20 > >My question was whether we want to allow the invocation of keep-alive > on that hop (Proxy1 to Proxy3) or whether we want to exclude this?=20 >=20 > Technically I see no harm in allowing sending keep-alives TO an entity > which didn't record-route, eventhough I am not sure it is useful. [JRE] That is not the point. I am asking about keep-alives between Proxy1 and Proxy3, both of which record-routed. John >=20 > However, I don't think it shall be possible to send=20 > keep-alives FROM an > entity which didn't record-route. Because, that entity would not know > when the registration, or the session, terminates, in order to stop > sending keep-alives. >=20 >=20 > >Bear in mind that the first mid-dialog request (excluding ACK)=20 > >could occur some considerable time after the call is=20 > >established (e.g., an UPDATE request when session timer=20 > >expires), so the benefit of keep-alive would last only=20 > >between that request and the final BYE request. >=20 > Yes. >=20 > But, I think that in many (most?) cases keep-alives will be=20 > sent between > entities which are going to be in the signalling path anyway. >=20 > For example, I think one of the most common use-case will be between a > UA and an edge proxy. So, the UA inserts "keep" in the Via of the > initial request, and the edge proxy will record-route and=20 > insert "yes". >=20 >=20 > >For SUBSCRIBE- and REFER-initiated dialogs it is a little simpler, > because there is always an immediate NOTIFY request to form=20 > the dialog. >=20 > Yes. >=20 > Regards, >=20 > Christer >=20 >=20 From christer.holmberg@ericsson.com Wed May 6 13:58:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7253A68C2 for ; Wed, 6 May 2009 13:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.857 X-Spam-Level: X-Spam-Status: No, score=-5.857 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L88Z4hNs6WVw for ; Wed, 6 May 2009 13:58:05 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B849F3A6DAE for ; Wed, 6 May 2009 13:58:04 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-6b-4a01fa327b0d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E9.F5.24713.23AF10A4; Wed, 6 May 2009 22:59:30 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 22:59:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 May 2009 22:59:29 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001DE1AD4@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tAAE5hMsAABMgsAAAEnoMAAAbpjoAAD+C6gAATyu1AAAnYTQAAPPTAQ References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15D2@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1785@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1AD4@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 06 May 2009 20:59:30.0108 (UTC) FILETIME=[8C955FC0:01C9CE8D] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 20:58:06 -0000 Hi,=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 06 May 2009 13:31 > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > Cc: SIPCORE > Subject: RE: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >=20 >=20 > Hi, >=20 > >>>Perhaps we might deliberately exclude the mechanism for use between > >>>two entities between which there was one or more non-record-routing > >>>proxy. > >>=20 > >>I am not sure I understand. The keep-alives are always between two=20 > >>neighbour entities. If there are other proxies (no matter > if they are > >>record-routing or not) between the two entities, thoe two entities=20 > >>will not send keep-alives between each other. When a SIP entity=20 > >>receives a request, it only checks the TOPMOST Via if it contains=20 > >>"keep", so if some other proxy has added a Via header > (without "keep") > no keep-alives will be sent. > >> > >[JRE] Suppose an INVITE request is routed: > > > >UA1 -> Proxy1 - >Proxy2 -> Proxy3 -> UA2 > > > >Suppose also that Proxy1 and Proxy3 record-route, but Proxy2 > does not. > > > >There is no point in doing keep-alive between Proxy1 and Proxy2, or > between Proxy2 and Proxy3. >=20 > Correct. So, in that case, if Proxy2 doesn't Record-Route, it should=20 > not insert "yes" in the Via received from Proxy1, and it should not=20 > insert "keep" in its Via sent towards Proxy3. >=20 >=20 > >When the first mid-dialog request is sent, it will go directly from > Proxy1 to Proxy3 or vice versa.=20 >=20 > Correct. >=20 >=20 > >My question was whether we want to allow the invocation of keep-alive > on that hop (Proxy1 to Proxy3) or whether we want to exclude this?=20 >=20 > Technically I see no harm in allowing sending keep-alives TO an entity > which didn't record-route, eventhough I am not sure it is useful. >[JRE] That is not the point. I am asking about keep-alives between >Proxy1 and Proxy3, both of which record-routed. In that case the top Via (Proxy2) will not contain the "keep" parameter. So, Proxy3 would need to make sure that the last entity (Proxy1) which inserted "keep" is also the last entity which record-routed. And, I am not sure we want to start comparing Via- and Record-Route headers in order to figure that out. An alternative would of course be to define "keep" as a Record-Route (and Path) parameter. Then it doesn't matter how many proxies (read: Via headers) there are between Proxy1 and Proxy3, as long as the top Record-Route contains the keep parameter. However, UAs don't insert Record-Route, so a UAC that supports sending of keep-alives would have to insert "keep" somewhere else. Regards, Christer > However, I don't think it shall be possible to send keep-alives FROM=20 > an entity which didn't record-route. Because, that entity would not=20 > know when the registration, or the session, terminates, in order to=20 > stop sending keep-alives. >=20 >=20 > >Bear in mind that the first mid-dialog request (excluding ACK) could=20 > >occur some considerable time after the call is established (e.g., an=20 > >UPDATE request when session timer expires), so the benefit of=20 > >keep-alive would last only between that request and the final BYE=20 > >request. >=20 > Yes. >=20 > But, I think that in many (most?) cases keep-alives will be sent=20 > between entities which are going to be in the signalling path anyway. >=20 > For example, I think one of the most common use-case will be between a > UA and an edge proxy. So, the UA inserts "keep" in the Via of the=20 > initial request, and the edge proxy will record-route and insert=20 > "yes". >=20 >=20 > >For SUBSCRIBE- and REFER-initiated dialogs it is a little simpler, > because there is always an immediate NOTIFY request to form the=20 > dialog. >=20 > Yes. >=20 > Regards, >=20 > Christer >=20 >=20 From john.elwell@siemens-enterprise.com Wed May 6 23:14:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5773A6C93 for ; Wed, 6 May 2009 23:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV+ZU9VWc6GY for ; Wed, 6 May 2009 23:14:39 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id DD3A93A69E2 for ; Wed, 6 May 2009 23:14:38 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJ900A2NG2I1H@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 07 May 2009 07:15:54 +0100 (BST) Date: Thu, 07 May 2009 07:15:52 +0100 From: "Elwell, John" In-reply-to: To: Christer Holmberg , "Tan, Ya Ching (NSN - DE/Munich)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001DE1B12@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tAAE5hMsAABMgsAAAEnoMAAAbpjoAAD+C6gAATyu1AAAnYTQAAPPTAQABOPqjA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15D2@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1785@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1AD4@GBNTHT12009MSX.gb002.siemens.net> Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 06:14:40 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 06 May 2009 21:59 > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > Cc: SIPCORE > Subject: RE: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >=20 >=20 > Hi,=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 06 May 2009 13:31 > > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > > Cc: SIPCORE > > Subject: RE: [sipcore] Draft submission:=20 > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > >=20 > >=20 > > Hi, > >=20 > > >>>Perhaps we might deliberately exclude the mechanism for=20 > use between >=20 > > >>>two entities between which there was one or more=20 > non-record-routing >=20 > > >>>proxy. > > >>=20 > > >>I am not sure I understand. The keep-alives are always=20 > between two=20 > > >>neighbour entities. If there are other proxies (no matter > > if they are > > >>record-routing or not) between the two entities, thoe two=20 > entities=20 > > >>will not send keep-alives between each other. When a SIP entity=20 > > >>receives a request, it only checks the TOPMOST Via if it contains=20 > > >>"keep", so if some other proxy has added a Via header > > (without "keep") > > no keep-alives will be sent. > > >> > > >[JRE] Suppose an INVITE request is routed: > > > > > >UA1 -> Proxy1 - >Proxy2 -> Proxy3 -> UA2 > > > > > >Suppose also that Proxy1 and Proxy3 record-route, but Proxy2 > > does not. > > > > > >There is no point in doing keep-alive between Proxy1 and Proxy2, or > > between Proxy2 and Proxy3. > >=20 > > Correct. So, in that case, if Proxy2 doesn't Record-Route,=20 > it should=20 > > not insert "yes" in the Via received from Proxy1, and it should not=20 > > insert "keep" in its Via sent towards Proxy3. > >=20 > >=20 > > >When the first mid-dialog request is sent, it will go directly from > > Proxy1 to Proxy3 or vice versa.=20 > >=20 > > Correct. > >=20 > >=20 > > >My question was whether we want to allow the invocation of=20 > keep-alive > > on that hop (Proxy1 to Proxy3) or whether we want to exclude this?=20 > >=20 > > Technically I see no harm in allowing sending keep-alives=20 > TO an entity >=20 > > which didn't record-route, eventhough I am not sure it is useful. > >[JRE] That is not the point. I am asking about keep-alives between > >Proxy1 and Proxy3, both of which record-routed. >=20 > In that case the top Via (Proxy2) will not contain the "keep"=20 > parameter. > So, Proxy3 would need to make sure that the last entity (Proxy1) which > inserted "keep" is also the last entity which record-routed. And, I am > not sure we want to start comparing Via- and Record-Route headers in > order to figure that out. [JRE] No, I would not want to do that. My point is that at the time of the dialog-forming request, there will be no direct transport connection between proxy1 and proxy3, so keep-alive is not relevant. However, as a result of the first mid-dialog request, there will be a direct transport connection between Proxy1 and Proxy3. So the question is whether we want to figure out a way of keeping that alive or not. >=20 > An alternative would of course be to define "keep" as a Record-Route > (and Path) parameter. Then it doesn't matter how many proxies=20 > (read: Via > headers) there are between Proxy1 and Proxy3, as long as the top > Record-Route contains the keep parameter. >=20 > However, UAs don't insert Record-Route, so a UAC that supports sending > of keep-alives would have to insert "keep" somewhere else. [JRE] And also it would not apply to REGISTER keep-alives. This would be a significant departure from what we are chartered to do - I am not sure we want to go there. To summarise: - The mechanism we currently have works for REGISTER-initiated keep-alives. - It also works for dialog-based keep-alives between entities that were adjacent at dialog-initiation time and remain on the dialog path. - It does not work for dialog-based keep-alives between entities that were not adjacent at dialog-initiation time but become adjacent subsequently (as a result of intermediate proxies not record-routing). The last case does not arise if B2BUAs are used or all proxies record-route. Does the WG want to address the last case or not? John From christer.holmberg@ericsson.com Thu May 7 07:45:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCD13A703D for ; Thu, 7 May 2009 07:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRpbqgfd7pVD for ; Thu, 7 May 2009 07:45:18 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 465773A7032 for ; Thu, 7 May 2009 07:45:16 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7bae000000a45-83-4a02cfe5e1c7 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 6E.12.02629.FDFC20A4; Thu, 7 May 2009 14:11:21 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 10:12:11 +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: Thu, 7 May 2009 10:12:09 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001DE1B12@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tAAE5hMsAABMgsAAAEnoMAAAbpjoAAD+C6gAATyu1AAAnYTQAAPPTAQABOPqjAABCDSIA== References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15D2@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1785@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1AD4@GBNTHT12009MSX.gb002.siemens.net> <0D5F 89FAC29E2C41B98A6A762007F5D001DE1B12@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 07 May 2009 08:12:11.0079 (UTC) FILETIME=[8598CD70:01C9CEEB] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 14:45:19 -0000 Hi,=20 > > > Hi, > > >=20 > > > >>>Perhaps we might deliberately exclude the mechanism for > > use between > >=20 > > > >>>two entities between which there was one or more > > non-record-routing > >=20 > > > >>>proxy. > > > >>=20 > > > >>I am not sure I understand. The keep-alives are always > > between two > > > >>neighbour entities. If there are other proxies (no matter > > > if they are > > > >>record-routing or not) between the two entities, thoe two > > entities > > > >>will not send keep-alives between each other. When a SIP entity=20 > > > >>receives a request, it only checks the TOPMOST Via if=20 > it contains=20 > > > >>"keep", so if some other proxy has added a Via header > > > (without "keep") > > > no keep-alives will be sent. > > > >> > > > >[JRE] Suppose an INVITE request is routed: > > > > > > > >UA1 -> Proxy1 - >Proxy2 -> Proxy3 -> UA2 > > > > > > > >Suppose also that Proxy1 and Proxy3 record-route, but Proxy2 > > > does not. > > > > > > > >There is no point in doing keep-alive between Proxy1 and=20 > Proxy2, or > > > between Proxy2 and Proxy3. > > >=20 > > > Correct. So, in that case, if Proxy2 doesn't Record-Route, > > it should > > > not insert "yes" in the Via received from Proxy1, and it=20 > should not=20 > > > insert "keep" in its Via sent towards Proxy3. > > >=20 > > >=20 > > > >When the first mid-dialog request is sent, it will go=20 > directly from > > > Proxy1 to Proxy3 or vice versa.=20 > > >=20 > > > Correct. > > >=20 > > >=20 > > > >My question was whether we want to allow the invocation of > > keep-alive > > > on that hop (Proxy1 to Proxy3) or whether we want to=20 > exclude this?=20 > > >=20 > > > Technically I see no harm in allowing sending keep-alives > > TO an entity > >=20 >>>which didn't record-route, eventhough I am not sure it is useful. >>>[JRE] That is not the point. I am asking about keep-alives between >>>Proxy1 and Proxy3, both of which record-routed. >>=20 >>In that case the top Via (Proxy2) will not contain the "keep" parameter. >>So, Proxy3 would need to make sure that the last entity (Proxy1) which >>inserted "keep" is also the last entity which record-routed. And, I am >>not sure we want to start comparing Via- and Record-Route headers in=20 >>order to figure that out. >[JRE] No, I would not want to do that. My point is that at=20 >the time of the dialog-forming request, there will be no=20 >direct transport connection between proxy1 and proxy3, so=20 >keep-alive is not relevant. However, as a result of the first=20 >mid-dialog request, there will be a direct transport=20 >connection between Proxy1 and Proxy3. So the question is=20 >whether we want to figure out a way of keeping that alive or not. I think there will be a direct transport connection between proxy1 and proxy3 already at the time of the response to the dialog-forming request. So, you can start sending keep-alives at that point. You don't need to wait for the first mid-dialog request. =20 >>An alternative would of course be to define "keep" as a Record-Route=20 >>and Path) parameter. Then it doesn't matter how many proxies >>(read: Via headers) there are between Proxy1 and Proxy3, as long as the top=20 >>Record-Route contains the keep parameter. >>=20 >>However, UAs don't insert Record-Route, so a UAC that supports sending >>of keep-alives would have to insert "keep" somewhere else. >[JRE] And also it would not apply to REGISTER keep-alives.=20 >This would be a significant departure from what we are=20 >chartered to do - I am not sure we want to go there. For REGISTER you would use the Path header. Outbound also uses that. Regards, Christer >To summarise: >- The mechanism we currently have works for REGISTER-initiated keep-alives. >- It also works for dialog-based keep-alives between entities=20 >that were adjacent at dialog-initiation time and remain on=20 >the dialog path. >- It does not work for dialog-based keep-alives between=20 >entities that were not adjacent at dialog-initiation time but=20 >become adjacent subsequently (as a result of intermediate=20 >proxies not record-routing). >=20 >The last case does not arise if B2BUAs are used or all=20 >proxies record-route. Does the WG want to address the last=20 >case or not? >=20 > John >=20 From pkyzivat@cisco.com Thu May 7 08:54:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776523A7055 for ; Thu, 7 May 2009 08:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3qwETJAukp6 for ; Thu, 7 May 2009 08:54:09 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4E33E3A6BFA for ; Thu, 7 May 2009 08:53:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,311,1238976000"; d="scan'208";a="43632709" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 May 2009 15:55:24 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n47FtO0J028047; Thu, 7 May 2009 11:55:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n47FtOcc029572; Thu, 7 May 2009 15:55:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 11:55:24 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 11:55:23 -0400 Message-ID: <4A030468.1050205@cisco.com> Date: Thu, 07 May 2009 11:55:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <4A019514.908@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2009 15:55:23.0905 (UTC) FILETIME=[3B697F10:01C9CF2C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6375; t=1241711724; x=1242575724; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Draft=20submission=3A=20dra ft-ietf-sipcore-keep-00=09(wasRE=3ADocument=0A=20Adoption) |Sender:=20 |To:=20Christer=20Holmberg=20; bh=co7uuiC80j7hHlHOpJ+6+4Sxl3zt3Q+J01HJA2jjNJk=; b=gfH/FOto/Lq4+HwViExaKjjs2zg4ep0PUgYOeq9G4BWY7UtH+lsKJMOoD1 lL748+4qeBL8yW7gdoFX3gZmI3zCHwt+cgb4iYZxmvFALE50UeebZYrDC6f0 sYZE+WH/Xp; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 15:54:10 -0000 Christer Holmberg wrote: > Hi, > >>> I think there are cases where you may record route because you want to > do keep-alives. >> Christer - can you explain that. I agree with John that it seems > backwards. What would be a use case where the decision the do keep > alives comes first and the need to r-r in order to be present for those >> keep alives is secondary? > > I am not sure I understand what is meant by "first and secondary". My > point is that an entity can choose to Record-Route because it wants to > either send or receive keep-alives (in the same way that it may choose > to record-record due to whatever other reasons). I agree that it *could* do that. But I fail to understand *why* it would do that? Aren't the keepalives there to assure there is a working communication path between them? If it has no other reason to be on a path, then why would it want the keepalives? They don't have value in their own right. > An edge proxy, if it > detects that the UA is behind a NAT, could Record-Route in order to > allow the UA to send keep-alives towards it. Maybe its just semantics, but in that case the reason it is R-R'ing is not because it wants to do keepalives. It is R-R'ing in order to maintain a working path to the UA. Doing keepalives is something else might need to do to keep that working path up. > But, of course, we can allow an entity to indicate that it is willing to > receive keep-alives (by inserting a "yes" value) even if it doesn't > record-route. Does that mean that keepalives should be sent even though the target of the keepalives is of no use? Thanks, Paul > Regards, > > Christer > > > > >> But, we don't need to argue about that. I guess your point is that we >> should allow the keep-alive negotiation also in mid-dialog request? >> >> Regards, >> >> Christer >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: 6. toukokuuta 2009 9:18 >>> To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) >>> Cc: SIPCORE >>> Subject: RE: [sipcore] Draft submission: >>> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >>> >>> Christer, >>> >>> That seems somewhat back-to-front. You don't record route (and hence >>> determine the path of the dialog) just because you want to do >>> keep-alives. You first decide whether you are to be on the path of a >>> dialog, and then you should decide whether to do keep-alives with >>> your neighbour. I guess where non-record-routing proxies are >>> involved, this can be achieved only on the first mid-dialog request. >>> However, for an INVITE-initiated dialog this might be the ACK >>> request, but unfortunately that doesn't have a response, so it is not > >>> suitable. In some cases it would be an UPDATE or PRACK request during > >>> the early dialog. For a >>> SUBSCRIBE- or REFER-initiated dialog it would be the first NOTIFY >>> request. >>> >>> In extending the keep-alive principle to dialogs, we need to be very >>> careful how we specify it. >>> >>> John >>> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: 05 May 2009 21:50 >>>> To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) >>>> Cc: SIPCORE >>>> Subject: RE: [sipcore] Draft submission: >>>> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >>>> >>>> >>>> Hi John, >>>> >>>> You raise a good point. The draft should probably say that a SIP >>>> entity MUST record-route (unless the entity is an endpoint) >>> if it is >>>> going to send and/or receive keep-alives. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Sent: Tuesday, May 05, 2009 4:53 PM >>>> To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) >>>> Cc: SIPCORE >>>> Subject: RE: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 >>>> (wasRE:Document Adoption) >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org >>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>>>> Sent: 05 May 2009 13:04 >>>>> To: Tan, Ya Ching (NSN - DE/Munich) >>>>> Cc: SIPCORE >>>>> Subject: Re: [sipcore] Draft submission: >>>>> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >>>>> >>>>> >>>>>> 3. The draft repeatedly uses the term 'initial SIP request'. >>>>>> What is the definition of this as it is not a known >>>> technical term in >>>> >>>>>> SIP [RFC 3261]. The sentence in Section 5 "If the UAC wishes to >>>>>> apply keep-alive for future calls, it MUST insert a "keep" Via >>>>>> parameter in the initial SIP request of those calls". >>>> This seems to >>>>>> imply that 'initial SIP request' >>>>>> means the initial INVITE. 'Initial INVITE' is what RFC >>> 3261 calls >>>>>> the dialog-initiating INVITE. Should the "keep" >>>>>> parameter in Via only be used in initial REGISTER and >>>>> initial INVITE ? >>>>> >>>>> I think that is the current assumption, yes, but I am not >>>> sure whether >>>>> we need to make that restriction. >>>>> >>>>> Regarding the usage of "initial SIP request", I guess it >>> should say >>>>> "initial SIP dialog request", or something like that. I >>>> think similar >>>>> wording is used in some places of the document. >>>> [JRE] So the sender of an "initial SIP dialog request" would invoke >>>> the capability between itself and the next downstream SIP entity. >>>> Presumably >>>> a SIP proxy that does not record-route would never invoke this >>>> capability. But what about the next SIP entity downstream, if that >>>> doesn't record-route? Presumably it too should refrain from >>> engaging >>>> in this capability. Mid-dialog requests would by-pass any >>>> non-record-routing proxies, so there would be no opportunity at the >>>> time of the "initial SIP dialog request" to create, and hence >>>> keep-alive, the connections needed for mid-dialog requests. >>> I couldn't >>>> find any discussion of this in the latest draft. >>>> >>>> John >>>> >>>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From christer.holmberg@ericsson.com Thu May 7 10:02:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA5328C2ED for ; Thu, 7 May 2009 10:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.862 X-Spam-Level: X-Spam-Status: No, score=-5.862 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WROUnQ+bj2DH for ; Thu, 7 May 2009 10:02:00 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BBC5128C2C6 for ; Thu, 7 May 2009 10:01:52 -0700 (PDT) X-AuditID: c1b4fb3c-b7b40ae000003af8-12-4a0314578bdd Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id BA.C6.15096.754130A4; Thu, 7 May 2009 19:03:19 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 19:03:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 19:03:18 +0200 Message-ID: In-Reply-To: <4A030468.1050205@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnPMA2z8IWSHWsuTVqmtJjjfry3nQABMDAA References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <4A019514.908@cisco.com> <4A030468.1050205@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 07 May 2009 17:03:19.0359 (UTC) FILETIME=[B8926CF0:01C9CF35] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 17:02:01 -0000 Hi,=20 >>>>I think there are cases where you may record route because you want=20 >>>>to do keep-alives. >>>Christer - can you explain that. I agree with John that it seems backwards. What would be a use case where the decision the do keep=20 >>>alives comes first and the need to r-r in order to be present for those >>>keep alives is secondary? >>=20 >>I am not sure I understand what is meant by "first and secondary". My=20 >>point is that an entity can choose to Record-Route because it wants to >>either send or receive keep-alives (in the same way that it may choose >>to record-record due to whatever other reasons). > >I agree that it *could* do that. >But I fail to understand *why* it would do that? >Aren't the keepalives there to assure there is a working communication path between them? If it has no other reason to be on a path, then why would it want the keepalives? They don't have value in their=20 >own right. I agree, so in that case there probably wouldn't be any keep-alives negotiated. The receiving entity would not Record-Route, and it would not insert "keep". But, the comments was that an entity first decides to Record-Route, and then decides to do keep-alives. So, when the entity has decided to Record-Route it can insert "keep" in the same request. >>An edge proxy, if it detects that the UA is behind a NAT, could Record-Route in order to=20 >>allow the UA to send keep-alives towards it. > >Maybe its just semantics, but in that case the reason it is R-R'ing is not because it wants to do keepalives. It is R-R'ing in order to maintain a working path to the UA. Doing keepalives is something=20 >else might need to do to keep that working path up. Yes. >>But, of course, we can allow an entity to indicate that it is willing=20 >>to receive keep-alives (by inserting a "yes" value) even if it doesn't >>record-route. > >Does that mean that keepalives should be sent even though the target of the keepalives is of no use? Well, if there is no use to send keep-alives, there will be no "yes" inserted. Assume I insert "keep", and forwards a request to you. No keep-alives are going to be sent until you actually add a "yes" value. And, if there is no reason for keep-alives you will not add "yes", and there won't be any keep-alives.=20 It is always the receiving entity which decides (by inserting "yes") whether there will be keep-alives or not. The sending entity only indicates (by inserting "keep") that he is able to send keep-alives. Regards, Christer > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >> But, we don't need to argue about that. I guess your point is that we >> should allow the keep-alive negotiation also in mid-dialog request? >> >> Regards, >> >> Christer >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: 6. toukokuuta 2009 9:18 >>> To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) >>> Cc: SIPCORE >>> Subject: RE: [sipcore] Draft submission:=20 >>> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >>> >>> Christer, >>> >>> That seems somewhat back-to-front. You don't record route (and hence >>> determine the path of the dialog) just because you want to do=20 >>> keep-alives. You first decide whether you are to be on the path of a >>> dialog, and then you should decide whether to do keep-alives with=20 >>> your neighbour. I guess where non-record-routing proxies are=20 >>> involved, this can be achieved only on the first mid-dialog request. >>> However, for an INVITE-initiated dialog this might be the ACK=20 >>> request, but unfortunately that doesn't have a response, so it is=20 >>> not >=20 >>> suitable. In some cases it would be an UPDATE or PRACK request=20 >>> during >=20 >>> the early dialog. For a >>> SUBSCRIBE- or REFER-initiated dialog it would be the first NOTIFY=20 >>> request. >>> >>> In extending the keep-alive principle to dialogs, we need to be very >>> careful how we specify it. >>> >>> John >>> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: 05 May 2009 21:50 >>>> To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) >>>> Cc: SIPCORE >>>> Subject: RE: [sipcore] Draft submission:=20 >>>> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >>>> >>>> >>>> Hi John, >>>> >>>> You raise a good point. The draft should probably say that a SIP=20 >>>> entity MUST record-route (unless the entity is an endpoint) >>> if it is >>>> going to send and/or receive keep-alives. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Sent: Tuesday, May 05, 2009 4:53 PM >>>> To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich) >>>> Cc: SIPCORE >>>> Subject: RE: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 >>>> (wasRE:Document Adoption) >>>> >>>> =20 >>>> >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org >>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>>>> Sent: 05 May 2009 13:04 >>>>> To: Tan, Ya Ching (NSN - DE/Munich) >>>>> Cc: SIPCORE >>>>> Subject: Re: [sipcore] Draft submission:=20 >>>>> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >>>>> >>>>> >>>>>> 3. The draft repeatedly uses the term 'initial SIP request'. =20 >>>>>> What is the definition of this as it is not a known >>>> technical term in >>>> >>>>>> SIP [RFC 3261]. The sentence in Section 5 "If the UAC wishes to=20 >>>>>> apply keep-alive for future calls, it MUST insert a "keep" Via=20 >>>>>> parameter in the initial SIP request of those calls". >>>> This seems to >>>>>> imply that 'initial SIP request' >>>>>> means the initial INVITE. 'Initial INVITE' is what RFC >>> 3261 calls >>>>>> the dialog-initiating INVITE. Should the "keep" >>>>>> parameter in Via only be used in initial REGISTER and >>>>> initial INVITE ? >>>>> >>>>> I think that is the current assumption, yes, but I am not >>>> sure whether >>>>> we need to make that restriction. >>>>> >>>>> Regarding the usage of "initial SIP request", I guess it >>> should say >>>>> "initial SIP dialog request", or something like that. I >>>> think similar >>>>> wording is used in some places of the document. >>>> [JRE] So the sender of an "initial SIP dialog request" would invoke >>>> the capability between itself and the next downstream SIP entity. >>>> Presumably >>>> a SIP proxy that does not record-route would never invoke this=20 >>>> capability. But what about the next SIP entity downstream, if that=20 >>>> doesn't record-route? Presumably it too should refrain from >>> engaging >>>> in this capability. Mid-dialog requests would by-pass any=20 >>>> non-record-routing proxies, so there would be no opportunity at the >>>> time of the "initial SIP dialog request" to create, and hence=20 >>>> keep-alive, the connections needed for mid-dialog requests. >>> I couldn't >>>> find any discussion of this in the latest draft. >>>> >>>> John >>>> >>>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >=20 From john.elwell@siemens-enterprise.com Thu May 7 12:59:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FABF3A68A3 for ; Thu, 7 May 2009 12:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWTcfO9ewXgO for ; Thu, 7 May 2009 12:59:44 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id D32143A719D for ; Thu, 7 May 2009 12:59:43 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJA00DBAI9W3C@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 07 May 2009 21:01:08 +0100 (BST) Date: Thu, 07 May 2009 21:01:11 +0100 From: "Elwell, John" In-reply-to: To: Christer Holmberg , "Tan, Ya Ching (NSN - DE/Munich)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001DE2078@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnJ10qZl3rT8XwGRfyZ7BCXFEAf4wCt0NigADfb5YAAAgphAAAEaiAAAA6z6tAAE5hMsAABMgsAAAEnoMAAAbpjoAAD+C6gAATyu1AAAnYTQAAPPTAQABOPqjAABCDSIAAY8FlQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49FA1267.5040204@nostrum.com> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF11D@DEMUEXC014.nsn-intra.net> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15D2@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1785@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1AD4@GBNTHT12009MSX.gb002.siemens.net> <"0D5F 89FAC29E2C41 B98A6A762007F5D001DE1B12"@GBNTHT12009MSX.gb002.siemens.net> Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 19:59:45 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 07 May 2009 09:12 > To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich) > Cc: SIPCORE > Subject: RE: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >=20 >=20 > Hi,=20 >=20 > > > > Hi, > > > >=20 > > > > >>>Perhaps we might deliberately exclude the mechanism for > > > use between > > >=20 > > > > >>>two entities between which there was one or more > > > non-record-routing > > >=20 > > > > >>>proxy. > > > > >>=20 > > > > >>I am not sure I understand. The keep-alives are always > > > between two > > > > >>neighbour entities. If there are other proxies (no matter > > > > if they are > > > > >>record-routing or not) between the two entities, thoe two > > > entities > > > > >>will not send keep-alives between each other. When a=20 > SIP entity=20 > > > > >>receives a request, it only checks the TOPMOST Via if=20 > > it contains=20 > > > > >>"keep", so if some other proxy has added a Via header > > > > (without "keep") > > > > no keep-alives will be sent. > > > > >> > > > > >[JRE] Suppose an INVITE request is routed: > > > > > > > > > >UA1 -> Proxy1 - >Proxy2 -> Proxy3 -> UA2 > > > > > > > > > >Suppose also that Proxy1 and Proxy3 record-route, but Proxy2 > > > > does not. > > > > > > > > > >There is no point in doing keep-alive between Proxy1 and=20 > > Proxy2, or > > > > between Proxy2 and Proxy3. > > > >=20 > > > > Correct. So, in that case, if Proxy2 doesn't Record-Route, > > > it should > > > > not insert "yes" in the Via received from Proxy1, and it=20 > > should not=20 > > > > insert "keep" in its Via sent towards Proxy3. > > > >=20 > > > >=20 > > > > >When the first mid-dialog request is sent, it will go=20 > > directly from > > > > Proxy1 to Proxy3 or vice versa.=20 > > > >=20 > > > > Correct. > > > >=20 > > > >=20 > > > > >My question was whether we want to allow the invocation of > > > keep-alive > > > > on that hop (Proxy1 to Proxy3) or whether we want to=20 > > exclude this?=20 > > > >=20 > > > > Technically I see no harm in allowing sending keep-alives > > > TO an entity > > >=20 > >>>which didn't record-route, eventhough I am not sure it is useful. > >>>[JRE] That is not the point. I am asking about keep-alives between > >>>Proxy1 and Proxy3, both of which record-routed. > >>=20 > >>In that case the top Via (Proxy2) will not contain the "keep" > parameter. > >>So, Proxy3 would need to make sure that the last entity=20 > (Proxy1) which >=20 > >>inserted "keep" is also the last entity which=20 > record-routed. And, I am >=20 > >>not sure we want to start comparing Via- and Record-Route=20 > headers in=20 > >>order to figure that out. > >[JRE] No, I would not want to do that. My point is that at=20 > >the time of the dialog-forming request, there will be no=20 > >direct transport connection between proxy1 and proxy3, so=20 > >keep-alive is not relevant. However, as a result of the first=20 > >mid-dialog request, there will be a direct transport=20 > >connection between Proxy1 and Proxy3. So the question is=20 > >whether we want to figure out a way of keeping that alive or not. >=20 > I think there will be a direct transport connection between proxy1 and > proxy3 already at the time of the response to the dialog-forming > request.=20 [JRE] I don't understand how that can happen, since the response will follow the path of the Via entries, not the path or record-routes. Please explain. John > So, you can start sending keep-alives at that point.=20 > You don't > need to wait for the first mid-dialog request. >=20 >=20 > =20 > >>An alternative would of course be to define "keep" as a=20 > Record-Route=20 > >>and Path) parameter. Then it doesn't matter how many proxies > >>(read: Via headers) there are between Proxy1 and Proxy3, as long as > the top=20 > >>Record-Route contains the keep parameter. > >>=20 > >>However, UAs don't insert Record-Route, so a UAC that=20 > supports sending >=20 > >>of keep-alives would have to insert "keep" somewhere else. > >[JRE] And also it would not apply to REGISTER keep-alives.=20 > >This would be a significant departure from what we are=20 > >chartered to do - I am not sure we want to go there. >=20 > For REGISTER you would use the Path header. Outbound also uses that. >=20 >=20 > Regards, >=20 > Christer >=20 >=20 > >To summarise: > >- The mechanism we currently have works for REGISTER-initiated > keep-alives. > >- It also works for dialog-based keep-alives between entities=20 > >that were adjacent at dialog-initiation time and remain on=20 > >the dialog path. > >- It does not work for dialog-based keep-alives between=20 > >entities that were not adjacent at dialog-initiation time but=20 > >become adjacent subsequently (as a result of intermediate=20 > >proxies not record-routing). > >=20 > >The last case does not arise if B2BUAs are used or all=20 > >proxies record-route. Does the WG want to address the last=20 > >case or not? > >=20 > > John > >=20 >=20 From spencer@wonderhamster.org Thu May 7 13:21:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0844D3A6B92 for ; Thu, 7 May 2009 13:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hALsk0ZFEhxO for ; Thu, 7 May 2009 13:21:29 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id B074F3A71A5 for ; Thu, 7 May 2009 13:20:52 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1M2A6d18Fy-000chn; Thu, 07 May 2009 16:22:16 -0400 Message-ID: <248CCDA78D424FD5A51EDFCDA9946E97@china.huawei.com> From: "Spencer Dawkins" To: "Elwell, John" , "Christer Holmberg" , "Tan, Ya Ching \(NSN - DE/Munich\)" References: 89FAC29E2C41B98A6A762007F5D001DE1B12"@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE2078@GBNTHT12009MSX.gb002.siemens.net> Date: Thu, 7 May 2009 15:21:47 -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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX188arILlry43KlzQ2VsBgHtmxuF0Swv4oHLPkI Qee5v3k85Zl3yzeZ+/e6+5uwb1H04uRj1pfTemWKAz8xO008nB kK9uVGeFxJd8AR4oDL+TsEJgqtSWpKGYTh/oz+RUDE= Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 20:21:30 -0000 >> >[JRE] No, I would not want to do that. My point is that at >> >the time of the dialog-forming request, there will be no >> >direct transport connection between proxy1 and proxy3, so >> >keep-alive is not relevant. However, as a result of the first >> >mid-dialog request, there will be a direct transport >> >connection between Proxy1 and Proxy3. So the question is >> >whether we want to figure out a way of keeping that alive or not. >> >> I think there will be a direct transport connection between proxy1 and >> proxy3 already at the time of the response to the dialog-forming >> request. > [JRE] I don't understand how that can happen, since the response will > follow the path of the Via entries, not the path or record-routes. > Please explain. I'm as confused as John is. For example, if the signaling path is using TCP, there would be a TCP connection between Proxy1 and Proxy2, and a separate TCP connection between Proxy2 and Proxy3, but this would not cause a SYN/SYN-ACK/ACK exchange between Proxy1 and Proxy3 - or am I missing something? Thanks, Spencer From christer.holmberg@ericsson.com Fri May 8 03:42:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A063A6C04 for ; Fri, 8 May 2009 03:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqHm7g1ooxjG for ; Fri, 8 May 2009 03:42:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 60A103A67EF for ; Fri, 8 May 2009 03:42:22 -0700 (PDT) X-AuditID: c1b4fb3c-b7b7fae0000015ab-88-4a040ce50554 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 02.87.05547.5EC040A4; Fri, 8 May 2009 12:43:49 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 May 2009 12:43: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 Date: Fri, 8 May 2009 12:43:48 +0200 Message-ID: In-Reply-To: <248CCDA78D424FD5A51EDFCDA9946E97@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnPUYWKcakLmMBrRHKBclyL6dMUZwAc8yKw References: 89FAC29E2C41B98A6A762007F5D001DE1B12"@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE2078@GBNTHT12009MSX.gb002.siemens.net> <248CCDA78D424FD5A51EDFCDA9946E97@china.huawei.com> From: "Christer Holmberg" To: "Spencer Dawkins" , "Elwell, John" , "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 08 May 2009 10:43:49.0039 (UTC) FILETIME=[DED113F0:01C9CFC9] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 10:42:23 -0000 Hi, >>>>[JRE] No, I would not want to do that. My point is that at the time=20 >>>>of the dialog-forming request, there will be no direct transport=20 >>>>connection between proxy1 and proxy3, so keep-alive is not relevant. >>>>However, as a result of the first mid-dialog request, there will be=20 >>>>a direct transport connection between Proxy1 and Proxy3. So the=20 >>>>question is whether we want to figure out a way of keeping that=20 >>>>alive or not. >>> >>>I think there will be a direct transport connection between proxy1 and >>>proxy3 already at the time of the response to the dialog-forming=20 >>>request. >>[JRE] I don't understand how that can happen, since the response will=20 >>follow the path of the Via entries, not the path or record-routes. >>Please explain. >=20 >I'm as confused as John is. For example, if the signaling=20 >path is using TCP, there would be a TCP connection between=20 >Proxy1 and Proxy2, and a separate TCP connection between=20 >Proxy2 and Proxy3, but this would not cause a SYN/SYN-ACK/ACK=20 >exchange between Proxy1 and Proxy3 - or am I missing something? No, you are not :) The TCP connection between Proxy1 and Proxy3 will be established when something is sent from Proxy1 to Proxy3. That would normally be a mid-dialog request, but it COULD of course also be the keep-alive message. But, if we don't want the keep-alive message to establish the TCP connection we can simply decide that keep-alives can be negotiated only between adjacent nodes, and we can keep the Via parameter based solution.=20 Then, it would not be possible to negotiate keep-alives between Proxy1 and Proxy3 during the initial request, since Proxy2 would still insert a Via (it would then be possible to negotiate keep-alives between Proxy1 and Proxy3 during a mid-dialog request, becuase then they will be adjacent). Regards, Christer From hisham.khartabil@gmail.com Sun May 10 16:24:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413683A6EEE for ; Sun, 10 May 2009 16:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+ePjOtDVbK6 for ; Sun, 10 May 2009 16:24:29 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id E6CEC28B23E for ; Sun, 10 May 2009 16:24:18 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so3054037ywj.49 for ; Sun, 10 May 2009 16:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i/OxClthVinZpDe54yg8HNptYWJLjdGq4NCKii8Xb5U=; b=Umq6zTmfbeJnB04HMgdPKYcLrlm8MANVQLBKa76rftIqSTxgKPVj2Pe376pnUSZKnv 797vfLDFxvf0tpp0s0SrfEsLXjeXksXRwYHF73xls0cP2QQHZ+E3nxg/etg7xGp7PGNF Z1Oc8f98RrA1WO29bMgwhpcPZg4U9xWBY9O1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FDGvAt5VqGSYGmwJ9q3N4YMUVUR91UhJSPftldOggRNir2mGg6Y1jcFhByH8M+vrMw urzJ7Or7HChOX3M1Hhnj25P+FeHMLw50JKu6IpN4gJY9eienF83CqixzGPao/9qx3hb7 gXDojr+mSbLbPttJnuWyBIn+EG+fOjcx+pjOY= MIME-Version: 1.0 Received: by 10.151.125.7 with SMTP id c7mr10068989ybn.144.1241997945509; Sun, 10 May 2009 16:25:45 -0700 (PDT) In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D001DE2078@GBNTHT12009MSX.gb002.siemens.net> <248CCDA78D424FD5A51EDFCDA9946E97@china.huawei.com> Date: Mon, 11 May 2009 09:25:45 +1000 Message-ID: <66cd252f0905101625nb9634b6g463a42b5469bff3e@mail.gmail.com> From: Hisham Khartabil To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2009 23:24:30 -0000 2009/5/8 Christer Holmberg : > > Hi, > >>>>>[JRE] No, I would not want to do that. My point is that at the time >>>>>of the dialog-forming request, there will be no direct transport >>>>>connection between proxy1 and proxy3, so keep-alive is not relevant. > >>>>>However, as a result of the first mid-dialog request, there will be >>>>>a direct transport connection between Proxy1 and Proxy3. So the >>>>>question is whether we want to figure out a way of keeping that >>>>>alive or not. >>>> >>>>I think there will be a direct transport connection between proxy1 > and >>>>proxy3 already at the time of the response to the dialog-forming >>>>request. >>>[JRE] I don't understand how that can happen, since the response will >>>follow the path of the Via entries, not the path or record-routes. >>>Please explain. >> >>I'm as confused as John is. For example, if the signaling >>path is using TCP, there would be a TCP connection between >>Proxy1 and Proxy2, and a separate TCP connection between >>Proxy2 and Proxy3, but this would not cause a SYN/SYN-ACK/ACK >>exchange between Proxy1 and Proxy3 - or am I missing something? > > No, you are not :) > > The TCP connection between Proxy1 and Proxy3 will be established when > something is sent from Proxy1 to Proxy3. That would normally be a > mid-dialog request, but it COULD of course also be the keep-alive > message. > > But, if we don't want the keep-alive message to establish the TCP > connection we can simply decide that keep-alives can be negotiated only > between adjacent nodes, and we can keep the Via parameter based > solution. > > Then, it would not be possible to negotiate keep-alives between Proxy1 > and Proxy3 during the initial request, since Proxy2 would still insert a > Via (it would then be possible to negotiate keep-alives between Proxy1 > and Proxy3 during a mid-dialog request, becuase then they will be > adjacent). John's query is not about the possibility of negotiating keep-alives between Proxy1 and Proxy3 during initial message exchange. He is asking if we have a requirement to negotiate keep-alives between proxy1 and proxy3 using mid-dialog messages. I think its a valid scenario and we should work on a solution. Hisham > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From drage@alcatel-lucent.com Mon May 11 06:13:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11AD13A6F50 for ; Mon, 11 May 2009 06:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[AWL=-1.711, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ3svcZ4Ezry for ; Mon, 11 May 2009 06:13:22 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id F387B3A6F3F for ; Mon, 11 May 2009 06:13:21 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4BDEmg7013815 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 May 2009 15:14:48 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 11 May 2009 15:14:48 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Dean Willis , Paul Kyzivat Date: Mon, 11 May 2009 15:14:48 +0200 Thread-Topic: [sipcore] Outbound: Flow-Timer only in REGISTER responses? Thread-Index: AcnOecHX6qeuxzkTQg+rbGtn8VJxaQAAkzlAAOmZVjA= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6759ECB1E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <790BEB01-41B2-4FEA-BF11-999837745FBD@softarmor.com> <3C48B0E939D44B7AB45CB63CAB85EE55@china.huawei.com> <4A01914E.4030308@cisco.com> <158210ED-C655-42BB-8722-C747A31100E1@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: SIPCORE Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER responses? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 13:13:23 -0000 I actually suggest that the tables are insufficient, and can only be regard= ed as a summary, therefore you do need to say precisely what is required in= the text as well (from both a sending and receiving perspective). And I wo= uld note that what is being specified in these tables is actually dynamic, = rather than some static conformance. I do not believe a maintained web site is the way to go - our external regi= stries are not there to specify behaviour, they are they to stop duplicate = assignment of values. If we go this way, we immediately run into the proble= m that the normative behaviour is meant to be specified in RFCs, so we stil= l have a maintenance problem. What I do suggest that in the text where you specify the usage of headers w= ithin individual methods, you try and be as method unspecific as possible. = If, for example, you are allowing a header to have meaning in REFER, INVITE= and SUBSCRIBE requests because they are all dialog creating requests, then= write the requirements as such. That way, if a new method is created, we c= an easily extrapolate this sort of text to the new method. Most of our head= er usage can be categorised fairly easily in this manner. Francois, your proposed outbound change belongs on the SIP list as that is = still PROTO shepherded there. Perhaps you can update with additions as I su= ggest above. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Wednesday, May 06, 2009 7:56 PM > To: Dean Willis; Paul Kyzivat > Cc: SIPCORE > Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER=20 > responses? >=20 >=20 > >>There is no way out - the interaction of a new method with=20 > all headers >=20 > >>and responses must be considered, and the interaction of a=20 > new header=20 > >>or response with all methods must be considered. > > > > > >Although strictly from a documentation procedure: the current format > wouldn't allow enough columns to appear in an internet-draft=20 > format to actually allow a new RFC to properly updated the table. > > > >Plus, there are a lot of "conditionals" encoded in the table as > additional row comments. I'm pretty sure that this confuses a=20 > lot of people -- I know it confuses me. Of course, it would=20 > help if we didn't=20 > >keep defining special cases of application-affecting-transport logic > like weird responses codes that Change the Rules. > > > >Perhaps some sort of formal language construct could express=20 > the logic > in some sort of fsm-verifiable way? >=20 > I guess we could start using the same mechanism as in 3GPP TS=20 > 24.229 Annex A. I am sure Keith would be more and happy to teach us :) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From root@core3.amsl.com Mon May 11 09:30:03 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AB9C53A6C77; Mon, 11 May 2009 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090511163003.AB9C53A6C77@core3.amsl.com> Date: Mon, 11 May 2009 09:30:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 16:30:03 -0000 --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 Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control Author(s) : A. Niemi, et al. Filename : draft-ietf-sipcore-event-rate-control-00.txt Pages : 21 Date : 2009-05-11 This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sipcore-event-rate-control-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-11092936.I-D@ietf.org> --NextPart-- From salvatore.loreto@ericsson.com Tue May 12 04:26:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC663A6AB8 for ; Tue, 12 May 2009 04:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u7zeJp6nM9j for ; Tue, 12 May 2009 04:26:57 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7A1903A6868 for ; Tue, 12 May 2009 04:26:56 -0700 (PDT) X-AuditID: c1b4fb3c-b7b2bae000003e37-3f-4a095d5aeb0c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id D5.0B.15927.A5D590A4; Tue, 12 May 2009 13:28:26 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 May 2009 13:28:26 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 May 2009 13:28:25 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F2594245F for ; Tue, 12 May 2009 14:28:25 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BF79E219F7 for ; Tue, 12 May 2009 14:28:25 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7D336219CF for ; Tue, 12 May 2009 14:28:25 +0300 (EEST) Message-ID: <4A095D59.6030909@ericsson.com> Date: Tue, 12 May 2009 14:28:25 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: sipcore@ietf.org References: <20090511163003.AB9C53A6C77@core3.amsl.com> In-Reply-To: <20090511163003.AB9C53A6C77@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 12 May 2009 11:28:26.0108 (UTC) FILETIME=[C42063C0:01C9D2F4] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 11:26:57 -0000 Hi there, I have submitted a new version of the "draft-niemi-sipping-event-throttle", this time as wg item. The draft is now named "draft-ietf-sipcore-event-rate-control" and the title has changed in: "Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control". in this version we have done the following changes to address all the feedbacks and suggestions we got in the mailing list discussion and during the last IETF meeting: - renamed the parameter names as "min-interval", "max-interval", "average-interval" - addressed the split of normative and non-normative sections and introduced some more normative sentences where we were lacking those - deleted some redundant text and merged some sections - clarified the text in several places using the newly chosen terminology: maximum/minimum/average rate mechanism - added some words about hidden throttling - inserted the suggestion we got about "not to break the normal retransmission mechanism" - some other more minor changes we haven't done any changes around the Timeout formula yet; as we do consider the formula in the draft just a possible suggestion (we will add some statement about this fact in the next version of the draft); a possible change could be add some additional formulas based on the suggestions we got in the mailing discussion and leave the choice of formula for implementation. cheers Sal Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > > Title : Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control > Author(s) : A. Niemi, et al. > Filename : draft-ietf-sipcore-event-rate-control-00.txt > Pages : 21 > Date : 2009-05-11 > > This document specifies mechanisms for adjusting the rate of Session > Initiation Protocol (SIP) event notifications. These mechanisms can > be applied in subscriptions to all SIP event packages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From john.elwell@siemens-enterprise.com Tue May 12 23:22:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292183A6E3C for ; Tue, 12 May 2009 23:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG3tXP2TBGHI for ; Tue, 12 May 2009 23:22:34 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 474863A6AEF for ; Tue, 12 May 2009 23:22:33 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJK00H23KG1SR@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 13 May 2009 07:24:02 +0100 (BST) Date: Wed, 13 May 2009 07:24:00 +0100 From: "Elwell, John" To: Cullen Jennings , Jon Peterson , SIPCORE Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001E19F19@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Inconsistency in RFC 3325? Thread-Index: AcnTk2eFL88fzp48TGO8p2k6477HCA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [sipcore] Inconsistency in RFC 3325? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 06:22:35 -0000 What looks like an inconsistency in RFC 3325 has been identified. The table in 9.2 states that PPI can be added ("a") by a proxy: " Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-Preferred-Identity adr - o - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o - - -" However, earlier in 9.2 it states: "The P-Preferred-Identity header field is used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert." i.e., no mention of being sent from a proxy. Moreover, in 6 it states: "The proxy MUST remove the user-provided P-Preferred- Identity header from any message it forwards." i.e., quite explicit about not forwarding, which one might also interpret as not being allowed to insert. So can PPI be added by a proxy, and if so what is its meaning? Has there been any earlier discussion on this topic? John From pkyzivat@cisco.com Wed May 13 06:06:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E83D3A6B43 for ; Wed, 13 May 2009 06:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfCPTpqtzijd for ; Wed, 13 May 2009 06:06:18 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A131A3A6C7A for ; Wed, 13 May 2009 06:05:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,187,1241395200"; d="scan'208";a="75797213" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 13 May 2009 13:07:18 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4DD7J7E017842; Wed, 13 May 2009 06:07:19 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4DD7Ii0010502; Wed, 13 May 2009 13:07:18 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 May 2009 09:07:18 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 May 2009 09:07:18 -0400 Message-ID: <4A0AC607.9050605@cisco.com> Date: Wed, 13 May 2009 09:07:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D001E19F19@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001E19F19@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2009 13:07:18.0175 (UTC) FILETIME=[BE53BAF0:01C9D3CB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1824; t=1242220039; x=1243084039; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Inconsistency=20in=20RFC=20 3325? |Sender:=20; bh=slrhy29INvIgX14+bE0uFh9eFUOP367EGF/Nr9dO56k=; b=ebheuMh8r0PsW4xDJzlkGXeUJ+kNISoMVgT4H5+7JjT4W32ZxZxZVFHsB/ saZVDOLlw/3KBSTIG1Sp9ZBr1+8Df1z/mSSf/TVfj/HuDVciwWbUTPTjhWBA 1jjro/hPMxyj+kzSFnIxcCz8IcRO2qHE5lYI35w6m/UPBp78UnyJ8=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Inconsistency in RFC 3325? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 13:06:20 -0000 John, I don't know if the proxy usage was intended or not. But neither do I see harm in permitting a proxy to insert the header. Perhaps there is a *really dumb* UA, with a proxy in front of it providing some smarts, before reaching the trusted (and secured) device that acts on the PPI. Thanks, Paul Elwell, John wrote: > What looks like an inconsistency in RFC 3325 has been identified. > > The table in 9.2 states that PPI can be added ("a") by a proxy: > " Header field where proxy ACK BYE CAN INV OPT REG > ------------ ----- ----- --- --- --- --- --- --- > P-Preferred-Identity adr - o - o o - > > > SUB NOT REF INF UPD PRA > --- --- --- --- --- --- > o o o - - -" > > However, earlier in 9.2 it states: > "The P-Preferred-Identity header field is used from a user agent to a > trusted proxy to carry the identity the user sending the SIP message > wishes to be used for the P-Asserted-Header field value that the > trusted element will insert." > i.e., no mention of being sent from a proxy. > > Moreover, in 6 it states: > "The proxy MUST remove the user-provided P-Preferred- > Identity header from any message it forwards." > i.e., quite explicit about not forwarding, which one might also > interpret as not being allowed to insert. > > So can PPI be added by a proxy, and if so what is its meaning? Has there > been any earlier discussion on this topic? > > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dean.willis@softarmor.com Wed May 13 07:41:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6EB3A6B83 for ; Wed, 13 May 2009 07:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiIJbSGNxDqX for ; Wed, 13 May 2009 07:41:56 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CBE9D3A6D5D for ; Wed, 13 May 2009 07:41:56 -0700 (PDT) Received: from [192.168.1.3] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4DEgIqe002198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 09:42:20 -0500 Message-ID: <4A0ADC45.4000405@softarmor.com> Date: Wed, 13 May 2009 09:42:13 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Paul Kyzivat References: <0D5F89FAC29E2C41B98A6A762007F5D001E19F19@GBNTHT12009MSX.gb002.siemens.net> <4A0AC607.9050605@cisco.com> In-Reply-To: <4A0AC607.9050605@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Inconsistency in RFC 3325? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 14:41:57 -0000 Paul Kyzivat wrote: > I don't know if the proxy usage was intended or not. > But neither do I see harm in permitting a proxy to insert the header. > Perhaps there is a *really dumb* UA, with a proxy in front of it > providing some smarts, before reaching the trusted (and secured) device > that acts on the PPI. I seem to recall discussing just exactly that use case. IIRC, somebody in 3GPP proposed that the P-CSCF should be able to insert the default preferred identity if the mobile terminal failed to insert one. > > Elwell, John wrote: >> What looks like an inconsistency in RFC 3325 has been identified. >> >> The table in 9.2 states that PPI can be added ("a") by a proxy: >> " Header field where proxy ACK BYE CAN INV OPT REG >> ------------ ----- ----- --- --- --- --- --- --- >> P-Preferred-Identity adr - o - o o - >> >> >> SUB NOT REF INF UPD PRA >> --- --- --- --- --- --- >> o o o - - -" >> There's that benighted table again. It confuses most people. It must be replaced. -- Dean From ietf.hanserik@gmail.com Wed May 13 11:43:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8DD3A6C8B for ; Wed, 13 May 2009 11:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7PW13nV7DwG for ; Wed, 13 May 2009 11:43:50 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 644AD3A69EC for ; Wed, 13 May 2009 11:43:50 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so242176eyd.31 for ; Wed, 13 May 2009 11:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=KCCnga2tWFuskjLrYNBBTQDgDiQ2vF3vFkmh0loVa6w=; b=iMnRFmx8fmO2GqAiI58yDfilqCyUxAL2KzwyQom4gHn5/ozKghQUF3o+CKCYteynnM ggWswg1bSwPSfXBypmFaZOp+dyBZL+/27Rau7AUnSfYdMuBssevIP0L8ymm25LfFl4D5 2aLBi0nBagTzPxkngT4E+KhqfC1U4aerUAX5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NlYq8qAGYRJncBTU8/+lMHFdKj1KMNSKFR/sU0IABJbL2LxCdQ3FfzRVCAfxz3q9+d e17MGc/bAuFcdh07rn5BnAJEXW+WZvRb5bYUWoFuULdW8kLDCHbb//ja6TxTqYoan986 jtetx7AAVkYrBkAv8NSbt+Ra9Wi4+aSewQj4w= Received: by 10.216.28.200 with SMTP id g50mr551246wea.203.1242240320524; Wed, 13 May 2009 11:45:20 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 7sm512221eyb.15.2009.05.13.11.45.19 (version=SSLv3 cipher=RC4-MD5); Wed, 13 May 2009 11:45:19 -0700 (PDT) Message-ID: <4A0B1541.5070001@gmail.com> Date: Wed, 13 May 2009 20:45:21 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D001E19F19@GBNTHT12009MSX.gb002.siemens.net> <4A0AC607.9050605@cisco.com> <4A0ADC45.4000405@softarmor.com> In-Reply-To: <4A0ADC45.4000405@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Inconsistency in RFC 3325? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 18:43:51 -0000 Seems off topic to discuss 3GPP behaviour here, but just to correct: the P-CSCF inserts a P-Asserted-Identity based or not on a P-Preferred-Identity, it will remove the latter. In case there is no P-Preferred-Identity it will insert the default identity in a P-Asserted-Identity. BR, /Hans Erik Dean Willis wrote: > Paul Kyzivat wrote: > >> I don't know if the proxy usage was intended or not. >> But neither do I see harm in permitting a proxy to insert the header. >> Perhaps there is a *really dumb* UA, with a proxy in front of it >> providing some smarts, before reaching the trusted (and secured) device >> that acts on the PPI. >> > > I seem to recall discussing just exactly that use case. IIRC, somebody > in 3GPP proposed that the P-CSCF should be able to insert the default > preferred identity if the mobile terminal failed to insert one. > > > >> Elwell, John wrote: >> >>> What looks like an inconsistency in RFC 3325 has been identified. >>> >>> The table in 9.2 states that PPI can be added ("a") by a proxy: >>> " Header field where proxy ACK BYE CAN INV OPT REG >>> ------------ ----- ----- --- --- --- --- --- --- >>> P-Preferred-Identity adr - o - o o - >>> >>> >>> SUB NOT REF INF UPD PRA >>> --- --- --- --- --- --- >>> o o o - - -" >>> >>> > > There's that benighted table again. It confuses most people. It must be > replaced. > > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From ietf.hanserik@gmail.com Wed May 13 11:56:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206003A6D60 for ; Wed, 13 May 2009 11:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT96MIJCMKOU for ; Wed, 13 May 2009 11:56:44 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 785AB28C202 for ; Wed, 13 May 2009 11:56:39 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so244199eyd.31 for ; Wed, 13 May 2009 11:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0cZE9hgNw6asFg6Oj50WRAZ0Ri6sK/MBqvVu3nNVoC4=; b=awtoqYd+I0yO4qWH6xBTxGbliumgTjkX96axXct3+LfSqH1r1yCWYTKJbRzJcLPSTC bgEnfGaKgdilDx0jTyOC2YHp5fa6wSBc6cEe2NQW4eO2YUwReOH8BoiqzZpnLR6sBhNU t51p5iMTfDduUxQHo6CnbcYbJ/Dqg+IsFJcBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BBCPhW4RJxRa0Jr12U0lBao4efhB7TCIUWIrmQjes5R3c5h6AvggHtoSuqeBwYX3Qe +Rr/q3MRro6ERpsLXe5R9dCrF+84yL+/7/kX7WQq+gTlP+zGRmaOgRz97WhSyjk3J+sl zcveni0g7lFD4OeZNkjI8DpUIA5jPwB2yuKN8= Received: by 10.216.49.211 with SMTP id x61mr539397web.222.1242241088435; Wed, 13 May 2009 11:58:08 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 7sm530310eyb.25.2009.05.13.11.58.07 (version=SSLv3 cipher=RC4-MD5); Wed, 13 May 2009 11:58:08 -0700 (PDT) Message-ID: <4A0B1841.8030200@gmail.com> Date: Wed, 13 May 2009 20:58:09 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D001E19F19@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001E19F19@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Inconsistency in RFC 3325? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 18:56:45 -0000 Hi John, If you cite the complete paragraph: "6. Hints for Multiple Identities If a P-Preferred-Identity header field is present in the message that a proxy receives from an entity that it does not trust, the proxy MAY use this information as a hint suggesting which of multiple valid identities for the authenticated user should be asserted. If such a hint does not correspond to any valid identity known to the proxy for that user, the proxy can add a P-Asserted-Identity header of its own construction, or it can reject the request (for example, with a 403 Forbidden). The proxy MUST remove the user-provided P-Preferred- Identity header from any message it forwards." then it is clear that "The proxy" is not just any proxy, but the "proxy that received the P-Preferred-Identity from an entity that it does not trust". It does therefore not say that any proxy shall in all circumstances remove P-Preferred-Identity. Hence, there is no conflict between the table and this text. but makes me wonder about the usefullness of these tables as they don't even say anything about what UA's are allowed to do or not... /Hans Erik Elwell, John wrote: > What looks like an inconsistency in RFC 3325 has been identified. > > The table in 9.2 states that PPI can be added ("a") by a proxy: > " Header field where proxy ACK BYE CAN INV OPT REG > ------------ ----- ----- --- --- --- --- --- --- > P-Preferred-Identity adr - o - o o - > > > SUB NOT REF INF UPD PRA > --- --- --- --- --- --- > o o o - - -" > > However, earlier in 9.2 it states: > "The P-Preferred-Identity header field is used from a user agent to a > trusted proxy to carry the identity the user sending the SIP message > wishes to be used for the P-Asserted-Header field value that the > trusted element will insert." > i.e., no mention of being sent from a proxy. > > Moreover, in 6 it states: > "The proxy MUST remove the user-provided P-Preferred- > Identity header from any message it forwards." > i.e., quite explicit about not forwarding, which one might also > interpret as not being allowed to insert. > > So can PPI be added by a proxy, and if so what is its meaning? Has there > been any earlier discussion on this topic? > > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dworley@nortel.com Wed May 13 14:04:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69B03A6FC4 for ; Wed, 13 May 2009 14:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOKdC70aZf65 for ; Wed, 13 May 2009 14:04:31 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 82AC03A6F04 for ; Wed, 13 May 2009 14:04:31 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4DL60P25218; Wed, 13 May 2009 21:06:00 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 May 2009 17:06:00 -0400 From: "Dale Worley" To: Dean Willis In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FA32E9.3070509@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> <1241474563.3833.23.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 13 May 2009 17:06:00 -0400 Message-Id: <1242248760.3756.64.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2009 21:06:00.0603 (UTC) FILETIME=[9E3A6EB0:01C9D40E] Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 21:04:32 -0000 On Mon, 2009-05-04 at 21:06 -0500, Dean Willis wrote: > On May 4, 2009, at 5:02 PM, Dale Worley wrote: > > > > The first sentence is close to what you have written, but as you note, > > that fact needs to be stated normatively. The second sentence talks > > about "Require" in a response, which is far as I can tell, has no > > defined meaning. > "Require" in a response has a defined meaning: It means that the > referenced extension was applied in formulating the response. Of > course, we have erroneous RFCs (including some I edited, dang it!) > that don't do this right. > > To quote RFC 3261 8.2.4 Applying Extensions: > > Any extensions applied to a non-421 response MUST be listed in a > > Require header field included in the response. Very good point. And now that you mention it, I have the annoying feeling that I knew that at some point. But this passage does mean that the meaning of Requires in responses is quite a bit different than the meaning in requests. There is some subtlety to the phrase "extension applied to a response": I believe that what is meant is not "the operations defined by the extension were applied when processing this request" but "this response cannot be properly understood by a UAC that does not support the extension [whatever that means]". That is, there are times when an extension is *used* by the UAS when processing a request but the UAS does not put a Requires header in the response. The obvious example is a registrar that constructs a GRUU for a registration of a UA, but the UA does not support GRUU, so the registrar does not add "Require: gruu" to the response, nor put the GRUU field-parameters in the Contact headers of the response. (Though ironically, if the UA ignores unknown field parameters correctly, the UA would *not* need to support GRUU to handle the GRUU field-parameters correctly.) Intriguingly, the only time such a Require is useful is if the UAC needs to know whether the extension was applied or not, and that fact is not indicated by any other information in the response. Do we have any extensions for which that can happen? > Note that the following sentence, also from that section, is under > debate -- I think it is not justifiable and should allow informational- > track RFCs. > > Of course, the server MUST NOT apply extensions not listed in the > > Supported header field in the request. As a result of this, the > > Require header field in a response will only ever contain option > > tags defined in standards- track RFCs. I'm not so worried about where the tags are defined, as a UAC can only see tags in responses that it understands. The central point is that the UAC can only receive "Requires: foo" in a response if it has declared "Supported: foo" in the request, so there can never be the problem of "receiving a response that contains a Requires tag that it does not understand". On Mon, 2009-05-04 at 20:57 -0500, Dean Willis wrote: > How about the authorization question: Christer requires the UAS to > support and use the Foo: extension, but Christer is not authorized to > use the Foo: extension at this UAS. UAS would be willing to process > the request for Christer without using Foo:, but SIP provides no > mechanism for UAS to tell Christer not to use Foo:. Although "Require: foo" in responses (or other indication of whether the foo extension was applied) does tell Christer whether his request to use foo was acted upon. On Tue, 2009-05-05 at 07:40 +0200, Christer Holmberg wrote: > Currently I wonder if there is a single extension which requires the UAC > to send Supported:foo in addition to Require:foo to indicate that the > UAC also supports the extension. The reason is probably that most (all?) > extensions do require some kind of support from both the UAC and UAS. Currently, I think the extensions fall into two categories, neither of which require such sophistication: 1) Extensions where the processing by each end is very similar, so that we expect that the "UAS implementation" and the "UAC implementation" can only be done together. I suspect that session-timers are like this (although I could be wrong, as I haven't studied session-timers). 2) Extensions where the relationship between the two UAs is inherently asymmetrical, and the respective roles are fixed with the first request. gruu and eventlist are like this. In the long run, there might be cases that fall into neither of these cases. In that case, the "obvious" logic is that a Requires demands that the UAS support the UAS-side of the extension. What Supported means is less obvious. Thinking about what has been said above, the one thing that Supported in a request *must* mean is that the UAC tolerates any extension-specific features in the response, equivalently, that Requires will be tolerated in the response. That means that Supported in a request says that the UAC supports the UAC-side of the extension. Dale From dworley@nortel.com Wed May 13 14:13:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218FA3A6AB2 for ; Wed, 13 May 2009 14:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL-z6U0c5xfK for ; Wed, 13 May 2009 14:13:36 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2EF423A683D for ; Wed, 13 May 2009 14:13:36 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4DLF5P27097 for ; Wed, 13 May 2009 21:15:05 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 May 2009 17:15:02 -0400 From: "Dale Worley" To: sipcore@ietf.org Content-Type: text/plain Organization: Nortel Networks Date: Wed, 13 May 2009 17:15:02 -0400 Message-Id: <1242249302.3756.68.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2009 21:15:02.0923 (UTC) FILETIME=[E179E5B0:01C9D40F] Subject: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 21:13:37 -0000 I wrote: Notifier migration is an interesting concept and seems like it might be very useful. But how does a subscriber take advantage of it? The text in 4.4.2 assumes that the subscriber will send a new out-of-dialog SUBSCRIBE to whatever URI it did originally. But will that obtain an alternative notifier for the resource whose notifier just ceased? The possibilities of SIP routing make that doubtful. What we want is for the notifier to give the subscriber a globally-routable URI that will reach an alternative notifier, but there seems to be no mechanism to carry the URI. I was thinking that a way to carry an alternative subscription address was in a Refer-To header. That has the right syntax and connotation. Dale From pkyzivat@cisco.com Thu May 14 06:18:14 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62733A6F4D for ; Thu, 14 May 2009 06:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2v0OX2yvTOP for ; Thu, 14 May 2009 06:18:13 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6587328C26A for ; Thu, 14 May 2009 06:15:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,194,1241395200"; d="scan'208";a="44203749" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 May 2009 13:17:26 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4EDHPvV020557; Thu, 14 May 2009 09:17:25 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4EDHPAn026875; Thu, 14 May 2009 13:17:25 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 09:17:25 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 09:17:25 -0400 Message-ID: <4A0C19E6.2000000@cisco.com> Date: Thu, 14 May 2009 09:17:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dale Worley References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FA32E9.3070509@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> <1241474563.3833.23.camel@victoria-pingtel-com.us.nortel.com> <1242248760.3756.64.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1242248760.3756.64.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2009 13:17:25.0512 (UTC) FILETIME=[52BDC080:01C9D496] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2550; t=1242307046; x=1243171046; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20 |To:=20Dale=20Worley=20; bh=QrrxPj0PGM9Bw5VjLZU/HvI6vdTD8YX38H+yQsj5xpQ=; b=QHNL4ltClPItlIM4n9c59ZC7crQP3uta8yNmaI3jyswrEqER8Kpg8ELtak pktCO8GY3UAmFyaRjt37cH93R0O5jQwafjSSambl9lXLe73hqPp31yi6cRsn SseY/YKCwp; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 13:18:14 -0000 Dale Worley wrote: > On Tue, 2009-05-05 at 07:40 +0200, Christer Holmberg wrote: >> Currently I wonder if there is a single extension which requires the UAC >> to send Supported:foo in addition to Require:foo to indicate that the >> UAC also supports the extension. The reason is probably that most (all?) >> extensions do require some kind of support from both the UAC and UAS. > > Currently, I think the extensions fall into two categories, neither of > which require such sophistication: > > 1) Extensions where the processing by each end is very similar, so that > we expect that the "UAS implementation" and the "UAC implementation" can > only be done together. I suspect that session-timers are like this > (although I could be wrong, as I haven't studied session-timers). > > 2) Extensions where the relationship between the two UAs is inherently > asymmetrical, and the respective roles are fixed with the first request. > gruu and eventlist are like this. > > In the long run, there might be cases that fall into neither of these > cases. In that case, the "obvious" logic is that a Requires demands > that the UAS support the UAS-side of the extension. > > What Supported means is less obvious. Thinking about what has been said > above, the one thing that Supported in a request *must* mean is that the > UAC tolerates any extension-specific features in the response, > equivalently, that Requires will be tolerated in the response. That > means that Supported in a request says that the UAC supports the > UAC-side of the extension. Mostly I think Dale is right here. But even in these kinds of cases there remains a level of ambiguity. Take for instance eventlist: If I am subscribing to some event, and include Supported:eventlist, then it does at least mean I can handle event lists in notifications I receive. But does it also mean that I could provide an event list if somebody sent a subscription to me? I guess you could say: try the subscribe and see what I say. That would be entirely appropriate if we can conclude that the significance of the Supported is bounded to the context in which it is used - the subscription in this case. But Supported in OPTIONS makes hash of that. Including Supported:eventlist in an OPTIONS could mean most anything. IMO, presence of almost anything in an OPTIONS is a very weak promise of support. At most I think it means: "I may support this feature in *some* context - your mileage may vary." Thanks, Paul From pkyzivat@cisco.com Fri May 15 16:37:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD593A6D8A for ; Fri, 15 May 2009 16:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df3D-0Sv2rHJ for ; Fri, 15 May 2009 16:37:41 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4C05F3A6A13 for ; Fri, 15 May 2009 16:37:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,202,1241395200"; d="scan'208";a="44394625" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 May 2009 23:39:14 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4FNdEQf000339 for ; Fri, 15 May 2009 19:39:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4FNdE5q021696 for ; Fri, 15 May 2009 23:39:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 19:39:14 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 19:39:14 -0400 Message-ID: <4A0DFD27.8070008@cisco.com> Date: Fri, 15 May 2009 19:39:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: sipcore@ietf.org References: <20090511163003.AB9C53A6C77@core3.amsl.com> In-Reply-To: <20090511163003.AB9C53A6C77@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2009 23:39:14.0526 (UTC) FILETIME=[5B0F3FE0:01C9D5B6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=895; t=1242430754; x=1243294754; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20I-D=20Action=3Adraft-ietf-s ipcore-event-rate-control-00.txt |Sender:=20 |To:=20sipcore@ietf.org; bh=nex7BkJWlrp0QfnBl7Iy7YD8PDay5m+4yZCyG4u/A6g=; b=QMOcvBZMk+JKVmT8M/ngcwrJMT9MIEe4BsunkcDy8wZKoGZxeI5PF5zVy7 cyly3XhScJTLRt+ygVnTyItvHHY+T3dqLI8wZoF2+GLkhDj2C+qDoeLmUexa XVMMQERU5U; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 23:37:45 -0000 Just a few comments: Section 3.1 is entitled: Use Case for maximizing the rate of notifications This wording isn't quite right, since "maximizing the rate" means "making the rate as large as possible". I would propose "Use case for limiting the maximum rate of notifications", or "Use Case for bounding the maximum notification rate". Similarly for section 3.2 (Use Case for minimizing the rate of notifications): I would suggest "Use Case for setting a minimum rate for notifications" or "Use Case for bounding the minimum rate of notification". In general its a little hard to read due to frequent switches between minimum-interval/maximum-rate and maximum-interval/minimum-rate. It might be clearer to discuss everything in terms of intervals, since that is what the parameters are. But if that isn't popular people will still figure it out. Thanks, Paul From fluffy@cisco.com Sun May 17 09:17:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FE93A6D67 for ; Sun, 17 May 2009 09:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-WcyEXnLzkS for ; Sun, 17 May 2009 09:17:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 32D5E3A6A42 for ; Sun, 17 May 2009 09:17:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,208,1241395200"; d="scan'208";a="305950871" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 17 May 2009 16:19:03 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4HGJ3O8013553; Sun, 17 May 2009 09:19:03 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4HGJ23Z005206; Sun, 17 May 2009 16:19:02 GMT From: Cullen Jennings To: Hans Erik van Elburg In-Reply-To: <4A0B1841.8030200@gmail.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <0D5F89FAC29E2C41B98A6A762007F5D001E19F19@GBNTHT12009MSX.gb002.siemens.net> <4A0B1841.8030200@gmail.com> Message-Id: <2A4D65BC-A8C3-4EA8-915F-9A560578D7B6@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 17 May 2009 10:19:01 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3603; t=1242577143; x=1243441143; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[sipcore]=20Inconsistency=20in=20RFC=20 3325? |Sender:=20; bh=BukhiOa3UBSaVieqGXvSs8OqPLsWLfXqTvQTWIFaUUw=; b=loHhUKAyxZXsBGhIzyL/pGs4HbdpGcHjA6S6q18M7dt3VTR1Xk/Aq3kGdT wePaSSUefkqBswnplGK9IIl7BTExrgj7+aaP4j1TP42b3NPdIbGRTsl4JaKL S2nQvN7JH/gDkt0UfNaqvdJvdnxH7rxunzDrPEpBsJr5/7g65tQfU=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Inconsistency in RFC 3325? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 16:17:29 -0000 On May 13, 2009, at 12:58 PM, Hans Erik van Elburg wrote: > Hi John, > > If you cite the complete paragraph: > "6. Hints for Multiple Identities > > If a P-Preferred-Identity header field is present in the message that > a proxy receives from an entity that it does not trust, the proxy MAY > use this information as a hint suggesting which of multiple valid > identities for the authenticated user should be asserted. If such a > hint does not correspond to any valid identity known to the proxy for > that user, the proxy can add a P-Asserted-Identity header of its own > construction, or it can reject the request (for example, with a 403 > Forbidden). The proxy MUST remove the user-provided P-Preferred- > Identity header from any message it forwards." > > then it is clear that "The proxy" is not just any proxy, but the > "proxy that received the P-Preferred-Identity from an entity that it > does not trust". > > > It does therefore not say that any proxy shall in all circumstances > remove P-Preferred-Identity. Agree with Hans. > > > Hence, there is no conflict between the table and this text. but > makes me wonder about the usefullness of these tables as they don't > even say anything about what UA's are allowed to do or not... INHO these tables have turned out to be pretty much useless (in this RFC, in 3261, and all the rest) but that's just my 2 cents The idea was to allow a proxy in front of a UA that did not support 3325 to add the PPI on behalf of the phone. Folks were imaging something like an little proxy on a box in my house adding it before it sent the call up to the service provider proxy. Clearly that idea did not get specified in this draft but the "a" got left in the proxy field. Keep that in this case, the proxy in the house trusts the service provider proxy but the service provider proxy does not trust the proxy in the house. Cullen < in my individual contributor roll > > > > /Hans Erik > > > Elwell, John wrote: >> What looks like an inconsistency in RFC 3325 has been identified. >> >> The table in 9.2 states that PPI can be added ("a") by a proxy: >> " Header field where proxy ACK BYE CAN INV >> OPT REG >> ------------ ----- ----- --- --- --- --- --- >> --- >> P-Preferred-Identity adr - o - o o - >> >> >> SUB NOT REF INF UPD >> PRA >> --- --- --- --- --- >> --- >> o o o - - >> -" >> >> However, earlier in 9.2 it states: >> "The P-Preferred-Identity header field is used from a user agent to a >> trusted proxy to carry the identity the user sending the SIP >> message >> wishes to be used for the P-Asserted-Header field value that the >> trusted element will insert." >> i.e., no mention of being sent from a proxy. >> >> Moreover, in 6 it states: >> "The proxy MUST remove the user-provided P-Preferred- >> Identity header from any message it forwards." >> i.e., quite explicit about not forwarding, which one might also >> interpret as not being allowed to insert. >> >> So can PPI be added by a proxy, and if so what is its meaning? Has >> there >> been any earlier discussion on this topic? >> >> John >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From dean.willis@softarmor.com Sun May 17 14:41:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11763A672F for ; Sun, 17 May 2009 14:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FXPGvb3GrYF for ; Sun, 17 May 2009 14:41:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9486D3A6C23 for ; Sun, 17 May 2009 14:41:20 -0700 (PDT) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4HLgpO9007900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 May 2009 16:42:53 -0500 Message-ID: <4A1084D6.8050500@softarmor.com> Date: Sun, 17 May 2009 16:42:46 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Paul Kyzivat References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FA32E9.3070509@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> <1241474563.3833.23.camel@victoria-pingtel-com.us.nortel.com> <1242248760.3756.64.camel@victoria-pingtel-com.us.nortel.com> <4A0C19E6.2000000@cisco.com> In-Reply-To: <4A0C19E6.2000000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE , Dale Worley Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 21:41:27 -0000 Paul Kyzivat wrote: > If I am subscribing to some event, and include Supported:eventlist, then > it does at least mean I can handle event lists in notifications I receive. > > But does it also mean that I could provide an event list if somebody > sent a subscription to me? eventlist as written seems to suffer from modal ambiguity. I suggest it requires two different option tags to resolve this ambiguity. -- Dean From christer.holmberg@ericsson.com Mon May 18 05:04:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6625F28C2A7 for ; Mon, 18 May 2009 05:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.868 X-Spam-Level: X-Spam-Status: No, score=-5.868 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYo0IBovi39z for ; Mon, 18 May 2009 05:04:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0229D3A7033 for ; Mon, 18 May 2009 05:04:55 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-43-4a114f3452b9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id B1.0E.02630.43F411A4; Mon, 18 May 2009 14:06:12 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 May 2009 14:06:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 May 2009 14:06:09 +0200 Message-ID: In-Reply-To: <66cd252f0905101625nb9634b6g463a42b5469bff3e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) Thread-Index: AcnRxqWvIUX6RCGlSxy3Ho502Kj3cQF5jGog References: <0D5F89FAC29E2C41B98A6A762007F5D001DE2078@GBNTHT12009MSX.gb002.siemens.net> <248CCDA78D424FD5A51EDFCDA9946E97@china.huawei.com> <66cd252f0905101625nb9634b6g463a42b5469bff3e@mail.gmail.com> From: "Christer Holmberg" To: "Hisham Khartabil" X-OriginalArrivalTime: 18 May 2009 12:06:12.0031 (UTC) FILETIME=[09334CF0:01C9D7B1] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 12:04:57 -0000 Hi, The requirements talk about negotiating keep-alives towards the next hop (UAC) and the previous hop (UAS), so in my opinion that only talks about adjacent nodes. We can of course argue whether we talk about nodes being adjacent during the routing of the initial INVITE, or nodes which become adjacent once the route set has been established :)=20 However, I think the only difference which headers we use for the negotiation. If we talk about adjacent nodes during routing of the initial INVITE the Via based solution works fine. If we talk about adjacent nodes in the route set I think we need to use e.g. Record-Route/Contact/Path. Of course we could use a Via based solution also for the second case, but then we need to establish the route set before we do the keep-alive negotiation, to make sure all Vias belong to entities in the route set. And, that also means a separate SIP transaction (UPDATE or PRACK) for the negotiation part. Regards, Christer=20 > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]=20 > Sent: 11. toukokuuta 2009 2:26 > To: Christer Holmberg > Cc: Spencer Dawkins; Elwell, John; Tan, Ya Ching (NSN -=20 > DE/Munich); SIPCORE > Subject: Re: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >=20 > 2009/5/8 Christer Holmberg : > > > > Hi, > > > >>>>>[JRE] No, I would not want to do that. My point is that=20 > at the time=20 > >>>>>of the dialog-forming request, there will be no direct transport=20 > >>>>>connection between proxy1 and proxy3, so keep-alive is=20 > not relevant. > > > >>>>>However, as a result of the first mid-dialog request,=20 > there will be=20 > >>>>>a direct transport connection between Proxy1 and Proxy3. So the=20 > >>>>>question is whether we want to figure out a way of keeping that=20 > >>>>>alive or not. > >>>> > >>>>I think there will be a direct transport connection between proxy1 > > and > >>>>proxy3 already at the time of the response to the dialog-forming=20 > >>>>request. > >>>[JRE] I don't understand how that can happen, since the=20 > response will=20 > >>>follow the path of the Via entries, not the path or record-routes. > >>>Please explain. > >> > >>I'm as confused as John is. For example, if the signaling path is=20 > >>using TCP, there would be a TCP connection between > >>Proxy1 and Proxy2, and a separate TCP connection between > >>Proxy2 and Proxy3, but this would not cause a=20 > SYN/SYN-ACK/ACK exchange=20 > >>between Proxy1 and Proxy3 - or am I missing something? > > > > No, you are not :) > > > > The TCP connection between Proxy1 and Proxy3 will be=20 > established when=20 > > something is sent from Proxy1 to Proxy3. That would normally be a=20 > > mid-dialog request, but it COULD of course also be the keep-alive=20 > > message. > > > > But, if we don't want the keep-alive message to establish the TCP=20 > > connection we can simply decide that keep-alives can be negotiated=20 > > only between adjacent nodes, and we can keep the Via=20 > parameter based=20 > > solution. > > > > Then, it would not be possible to negotiate keep-alives=20 > between Proxy1=20 > > and Proxy3 during the initial request, since Proxy2 would=20 > still insert=20 > > a Via (it would then be possible to negotiate keep-alives between=20 > > Proxy1 and Proxy3 during a mid-dialog request, becuase then=20 > they will=20 > > be adjacent). >=20 > John's query is not about the possibility of negotiating=20 > keep-alives between Proxy1 and Proxy3 during initial message=20 > exchange. He is asking if we have a requirement to negotiate=20 > keep-alives between > proxy1 and proxy3 using mid-dialog messages. >=20 > I think its a valid scenario and we should work on a solution. >=20 > Hisham >=20 > > > > Regards, > > > > Christer > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 From adam@nostrum.com Tue May 19 16:24:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9053A6E5C for ; Tue, 19 May 2009 16:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwHC3-LVD-xI for ; Tue, 19 May 2009 16:24:29 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3B7FD3A68D0 for ; Tue, 19 May 2009 16:24:29 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-101.dsl.rcsntx.swbell.net [70.249.149.101]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n4JNQ1mb084809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2009 18:26:01 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A134009.5040504@nostrum.com> Date: Tue, 19 May 2009 18:26:01 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FA32E9.3070509@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> <1241474563.3833.23.camel@victoria-pingtel-com.us.nortel.com> <1242248760.3756.64.camel@victoria-pingtel-com.us.nortel.com> <4A0C19E6.2000000@cisco.com> <4A1084D6.8050500@softarmor.com> In-Reply-To: <4A1084D6.8050500@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.101 is authenticated by a trusted mechanism) Cc: SIPCORE , Dale Worley Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 23:24:30 -0000 [as an individual] Dean Willis wrote: > Paul Kyzivat wrote: > >> If I am subscribing to some event, and include Supported:eventlist, then >> it does at least mean I can handle event lists in notifications I receive. >> >> But does it also mean that I could provide an event list if somebody >> sent a subscription to me? >> > > eventlist as written seems to suffer from modal ambiguity. I suggest it > requires two different option tags to resolve this ambiguity. > Almost every use of option tags specific to subscriptions is going to suffer from the same "ambiguity" to varying degrees. With INVITE-initiated dialogs, the behavior is symmetrical: both participants serve the same role in the dialog. With SUBSCRIBE/NOTIFY-initiated dialogs, the roles are inherently asymmetrical -- one party is a subscriber, while the other is a notifier. So, if we plan to come up with some "Grand Unified Theory" of option tag semantics and publish it as an RFC or part of an RFC, we should probably include this as a base principle. I would suggest one of the participants in this discussion take the arguments so far and summarize them in an internet-draft, taking this into account. On the other hand, if we're just grousing to pass the time, I'd prefer to do that on idle Friday afternoons over beer rather than on the list. ;-) /a From dean.willis@softarmor.com Wed May 20 11:35:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8403D3A7145 for ; Wed, 20 May 2009 11:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y30UWT3MIeMq for ; Wed, 20 May 2009 11:35:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C6D2F3A712D for ; Wed, 20 May 2009 11:35:03 -0700 (PDT) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4KIaFpr001671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 May 2009 13:36:17 -0500 Message-ID: <4A144D98.6030304@softarmor.com> Date: Wed, 20 May 2009 13:36:08 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Adam Roach References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <49FA32E9.3070509@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F2@GBNTHT12009MSX.gb002.siemens.net> <1241474563.3833.23.camel@victoria-pingtel-com.us.nortel.com> <1242248760.3756.64.camel@victoria-pingtel-com.us.nortel.com> <4A0C19E6.2000000@cisco.com> <4A1084D6.8050500@softarmor.com> <4A134009.5040504@nostrum.com> In-Reply-To: <4A134009.5040504@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE , Dale Worley Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 18:35:04 -0000 Adam Roach wrote: > On the other hand, if we're just grousing to pass the time, I'd prefer > to do that on idle Friday afternoons over beer rather than on the list. ;-) Why would we want to interfere with something important like Friday afternoon beer time by talking about option tags that everybody has already gotten wrong? -- Dean From adam@nostrum.com Thu May 21 15:05:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28FB83A6C60; Thu, 21 May 2009 15:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZSf8Xnr1O4N; Thu, 21 May 2009 15:05:25 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D6E2C3A6964; Thu, 21 May 2009 15:05:24 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n4LM711k021133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2009 17:07:01 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A15D085.9070704@nostrum.com> Date: Thu, 21 May 2009 17:07:01 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Internet-Drafts@ietf.org References: <20090504221501.62CC83A6C6D@core3.amsl.com> In-Reply-To: <20090504221501.62CC83A6C6D@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org, i-d-announce@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 22:05:26 -0000 [as chair] I'd like to thank Brian for taking over editorship of this document, which has been mostly complete (pending some syntax issues) for several years now. Keeping in mind that this document is an adopted SIPCORE working group item, I would encourage everyone to read over it, and provide comments to the list. Even a quick note saying something like "I read through this, understood it, and think the examples are correct" is useful. Of course, something like "I untarred the examples and independently verified them with my own implementation" would be spectacular. /a Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > > Title : Example call flows using Session Initiation Protocol (SIP) security mechanisms > Author(s) : C. Jennings, et al. > Filename : draft-ietf-sipcore-sec-flows-00.txt > Pages : 59 > Date : 2009-05-04 > > This document shows example call flows demonstrating the use of > Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail > Extensions (S/MIME) in Session Initiation Protocol (SIP). It also > provides information that helps implementers build interoperable SIP > software. To help facilitate interoperability testing, it includes > certificates used in the example call flows and processes to create > certificates for testing. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Fri May 22 12:12:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60123A7067 for ; Fri, 22 May 2009 12:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d279yF6v7Tz0 for ; Fri, 22 May 2009 12:12:10 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A49373A6C01 for ; Fri, 22 May 2009 12:12:09 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n4MJDhJZ016575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 14:13:43 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A16F967.6050509@nostrum.com> Date: Fri, 22 May 2009 14:13:43 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] IETF 75: Agenda Time Requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 19:12:11 -0000 [as chair] In keeping with the spirit of our charter, we intend to run SIPCORE face-to-face meetings in a very focused fashion. To that end, requests for SIPCORE agenda time need to contain the following information: 1. The name of the draft or drafts under discussion 2. A list of open issues to be addressed 3. A pointer to non-trivial mailing list discussion of the draft (the subject line of associated threads is sufficient) Presentations are expected to be focused around the list of open issues, not the general contents of or changes to the document. Tutorial content must be limited to explaining the open issues and potential resolutions to those issues. Please note that it will be very difficult to have non-trivial mailing list discussion of drafts that are submitted very close to the document submission deadlines. We strongly encourage authors who plan to request agenda time to publish a revised document well ahead of the deadlines. Currently, we have requested a total of 3.5 hours of meeting time at the upcoming meeting in Stockholm this July. Depending on the total number of open issues and the associated volume of mailing list traffic, we may reduce this to 2.5 hours or even 1 hour. If you wish to request agenda time, please send these three pieces of information to the SIPCORE chairs on or before June 3rd. Length of timeslots will be determined based on the number and complexity of open issues in the agenda request. If a new open issue arises after submission of a request, please notify the chairs so that we can adjust timeslots accordingly. For the sake of clarity: the discussion will not be limited to the open items listed in your request; it can include open items that arise after you submit your request. So, if your list of open items is somewhat weak but you expect that difficult points may arise between June 3rd and the Stockholm meeting, please send in a request indicating that fact. /a From dean.willis@softarmor.com Sun May 24 02:05:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B34228C0D9 for ; Sun, 24 May 2009 02:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUOFIVq7FAsq for ; Sun, 24 May 2009 02:05:20 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5433528C0ED for ; Sun, 24 May 2009 02:05:20 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4O96wd1031882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 24 May 2009 04:06:59 -0500 Message-Id: <7C02FC67-DAAC-421A-BA79-7047F8ADDC12@softarmor.com> From: Dean Willis To: Adam Roach Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 24 May 2009 04:06:52 -0500 X-Mailer: Apple Mail (2.935.3) Cc: SIPCORE Subject: [sipcore] Proto writeup for draft-ietf-sipcore-subnot-etags-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2009 09:05:21 -0000 SIPCORE chair Adam Roach has asked me to serve as the protocol shepherd for the subnot-etags work. Consequently, I've prepared the following writeup. As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Dean Willis. He has reviewed this document and believes it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been widely reviewed within the working group. Dale Worley in particular provided some detailed analysis, and Eric Rescorla also performed useful review leading to subtle changes in the document. Paul Kyzivat provided further assistance with correcting the ABNF during the final review process, and Adam Roach reviewed the document from perspective of RFC 3265. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no shepherd concerns, and the shepherd is unaware of specific IPR disclosures. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document was widely reviewed within the working group between August, 2007 and October, 2008. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There appears to be no extreme discontent or significant conflict surrounding the draft. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The shepherd checked idnits, validated BNF using BAP, and did the usual visual review of the document. There are no formal criteria review for this document. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References appear to be appropriate. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations appear to be appropriate. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains only a trivial BNF for a SIP response code and another very small addition for a message-header. The BNF was verified using BAP. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Document Writeup Technical Summary The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These SIP Events Framework procedures have a serious deficiency in that they provide no tools to avoid replaying event notifications that have already been received by a user agent. This specification defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. This "conditioning" of the subscription requests uses the well-known concept of entity tags (eTags). Working Group Summary This document received extended working group review during a WGLC period that exceeded one year in duration. One critical clarification came up in this review period: this specification does not provide "versioning history" for events; rather it lets a subscriber know whether the current event state is consistent with the event state as currently known by that subscriber. The distinction is subtle. For example, if the subscriber knows of event state "A", but the actual state has changed to "B" and then back to "A", the subscriber will not be informed about the B state through this specification. Following WGLC, the proto review process detected and corrected a minor error in the ABNF, and further review by Adam Roach detected and corrected problem related to suppressed NOTIFYs on initial dialogs. Document Quality The Open Mobile Alliance SIMPLE Presence specification references this document, and has done so for several years. Note that the most recent OMA document the shepherd could locate references draft-ietf-sip-subnot-etags-03.txt rather than the current specification. From christer.holmberg@ericsson.com Sun May 24 22:47:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863C53A6C35 for ; Sun, 24 May 2009 22:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo6pv4JoQt1Y for ; Sun, 24 May 2009 22:47:29 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 484DE3A6A99 for ; Sun, 24 May 2009 22:47:28 -0700 (PDT) X-AuditID: c1b4fb3e-b7b8aae000007ae8-12-4a1a31531274 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 98.A1.31464.3513A1A4; Mon, 25 May 2009 07:49:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 07:49:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 May 2009 07:49:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-keep-00(wasRE:Document Adoption) Thread-Index: AcnRxqWvIUX6RCGlSxy3Ho502Kj3cQF5jGogAVPYVxA= References: <0D5F89FAC29E2C41B98A6A762007F5D001DE2078@GBNTHT12009MSX.gb002.siemens.net><248CCDA78D424FD5A51EDFCDA9946E97@china.huawei.com><66cd252f0905101625nb9634b6g463a42b5469bff3e@mail.gmail.com> From: "Christer Holmberg" To: "SIPCORE" X-OriginalArrivalTime: 25 May 2009 05:49:07.0359 (UTC) FILETIME=[84BC92F0:01C9DCFC] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00(wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 05:47:36 -0000 =20 Hi, My proposal would be that we keep the Via based solution. That allows negotiation as part of of keep-alives in any transaction. A Record-Route based solution only allowes the negotiation during the initial dialog transaction, since the route set can't be modified later during the dialog. Are people ok with that? Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 18. toukokuuta 2009 15:06 > To: Hisham Khartabil > Cc: SIPCORE > Subject: Re: [sipcore] Draft submission:=20 > draft-ietf-sipcore-keep-00(wasRE:Document Adoption) >=20 >=20 > Hi, >=20 > The requirements talk about negotiating keep-alives towards=20 > the next hop > (UAC) and the previous hop (UAS), so in my opinion that only=20 > talks about adjacent nodes. >=20 > We can of course argue whether we talk about nodes being=20 > adjacent during the routing of the initial INVITE, or nodes=20 > which become adjacent once the route set has been established :)=20 >=20 > However, I think the only difference which headers we use for=20 > the negotiation. >=20 > If we talk about adjacent nodes during routing of the initial=20 > INVITE the Via based solution works fine. >=20 > If we talk about adjacent nodes in the route set I think we=20 > need to use e.g. Record-Route/Contact/Path. >=20 > Of course we could use a Via based solution also for the=20 > second case, but then we need to establish the route set=20 > before we do the keep-alive negotiation, to make sure all=20 > Vias belong to entities in the route set. > And, that also means a separate SIP transaction (UPDATE or=20 > PRACK) for the negotiation part. >=20 > Regards, >=20 > Christer=20 >=20 >=20 > > -----Original Message----- > > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > > Sent: 11. toukokuuta 2009 2:26 > > To: Christer Holmberg > > Cc: Spencer Dawkins; Elwell, John; Tan, Ya Ching (NSN - DE/Munich);=20 > > SIPCORE > > Subject: Re: [sipcore] Draft submission:=20 > > draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) > >=20 > > 2009/5/8 Christer Holmberg : > > > > > > Hi, > > > > > >>>>>[JRE] No, I would not want to do that. My point is that > > at the time > > >>>>>of the dialog-forming request, there will be no direct=20 > transport=20 > > >>>>>connection between proxy1 and proxy3, so keep-alive is > > not relevant. > > > > > >>>>>However, as a result of the first mid-dialog request, > > there will be > > >>>>>a direct transport connection between Proxy1 and=20 > Proxy3. So the=20 > > >>>>>question is whether we want to figure out a way of=20 > keeping that=20 > > >>>>>alive or not. > > >>>> > > >>>>I think there will be a direct transport connection=20 > between proxy1 > > > and > > >>>>proxy3 already at the time of the response to the=20 > dialog-forming=20 > > >>>>request. > > >>>[JRE] I don't understand how that can happen, since the > > response will > > >>>follow the path of the Via entries, not the path or=20 > record-routes. > > >>>Please explain. > > >> > > >>I'm as confused as John is. For example, if the signaling path is=20 > > >>using TCP, there would be a TCP connection between > > >>Proxy1 and Proxy2, and a separate TCP connection between > > >>Proxy2 and Proxy3, but this would not cause a > > SYN/SYN-ACK/ACK exchange > > >>between Proxy1 and Proxy3 - or am I missing something? > > > > > > No, you are not :) > > > > > > The TCP connection between Proxy1 and Proxy3 will be > > established when > > > something is sent from Proxy1 to Proxy3. That would normally be a=20 > > > mid-dialog request, but it COULD of course also be the keep-alive=20 > > > message. > > > > > > But, if we don't want the keep-alive message to establish the TCP=20 > > > connection we can simply decide that keep-alives can be=20 > negotiated=20 > > > only between adjacent nodes, and we can keep the Via > > parameter based > > > solution. > > > > > > Then, it would not be possible to negotiate keep-alives > > between Proxy1 > > > and Proxy3 during the initial request, since Proxy2 would > > still insert > > > a Via (it would then be possible to negotiate keep-alives between > > > Proxy1 and Proxy3 during a mid-dialog request, becuase then > > they will > > > be adjacent). > >=20 > > John's query is not about the possibility of negotiating=20 > keep-alives=20 > > between Proxy1 and Proxy3 during initial message exchange. He is=20 > > asking if we have a requirement to negotiate keep-alives between > > proxy1 and proxy3 using mid-dialog messages. > >=20 > > I think its a valid scenario and we should work on a solution. > >=20 > > Hisham > >=20 > > > > > > Regards, > > > > > > Christer > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From mdolly@att.com Mon May 25 02:36:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E943A6880 for ; Mon, 25 May 2009 02:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9++iSTzrtO0X for ; Mon, 25 May 2009 02:36:18 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id B96CD3A6BB9 for ; Mon, 25 May 2009 02:35:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-11.tower-161.messagelabs.com!1243244257!5753833!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 1814 invoked from network); 25 May 2009 09:37:37 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-11.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 May 2009 09:37:37 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n4P9bb3f030103 for ; Mon, 25 May 2009 05:37:37 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n4P9bVuD030074 for ; Mon, 25 May 2009 05:37:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 25 May 2009 05:37:30 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD47A2@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft submission:draft-ietf-sipcore-keep-00(wasRE:Document Adoption) Thread-Index: AcnRxqWvIUX6RCGlSxy3Ho502Kj3cQF5jGogAVPYVxAACA0BVw== From: "DOLLY, MARTIN C, ATTLABS" To: , Subject: Re: [sipcore] Draft submission:draft-ietf-sipcore-keep-00(wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 09:36:20 -0000 V2Ugc3VwcG9ydCB0aGF0DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IHNp cGNvcmUtYm91bmNlc0BpZXRmLm9yZyA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPg0KVG86IFNJ UENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+DQpTZW50OiBNb24gTWF5IDI1IDAxOjQ5OjA2IDIwMDkN ClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRHJhZnQgc3VibWlzc2lvbjpkcmFmdC1pZXRmLXNpcGNv cmUta2VlcC0wMCh3YXNSRTpEb2N1bWVudCBBZG9wdGlvbikNCg0KDQogDQpIaSwNCg0KTXkgcHJv cG9zYWwgd291bGQgYmUgdGhhdCB3ZSBrZWVwIHRoZSBWaWEgYmFzZWQgc29sdXRpb24uDQoNClRo YXQgYWxsb3dzIG5lZ290aWF0aW9uIGFzIHBhcnQgb2Ygb2Yga2VlcC1hbGl2ZXMgaW4gYW55IHRy YW5zYWN0aW9uLiBBDQpSZWNvcmQtUm91dGUgYmFzZWQgc29sdXRpb24gb25seSBhbGxvd2VzIHRo ZSBuZWdvdGlhdGlvbiBkdXJpbmcgdGhlDQppbml0aWFsIGRpYWxvZyB0cmFuc2FjdGlvbiwgc2lu Y2UgdGhlIHJvdXRlIHNldCBjYW4ndCBiZSBtb2RpZmllZCBsYXRlcg0KZHVyaW5nIHRoZSBkaWFs b2cuDQoNCkFyZSBwZW9wbGUgb2sgd2l0aCB0aGF0Pw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZyANCj4gW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KPiBTZW50OiAxOC4gdG91a29rdXV0YSAyMDA5IDE1 OjA2DQo+IFRvOiBIaXNoYW0gS2hhcnRhYmlsDQo+IENjOiBTSVBDT1JFDQo+IFN1YmplY3Q6IFJl OiBbc2lwY29yZV0gRHJhZnQgc3VibWlzc2lvbjogDQo+IGRyYWZ0LWlldGYtc2lwY29yZS1rZWVw LTAwKHdhc1JFOkRvY3VtZW50IEFkb3B0aW9uKQ0KPiANCj4gDQo+IEhpLA0KPiANCj4gVGhlIHJl cXVpcmVtZW50cyB0YWxrIGFib3V0IG5lZ290aWF0aW5nIGtlZXAtYWxpdmVzIHRvd2FyZHMgDQo+ IHRoZSBuZXh0IGhvcA0KPiAoVUFDKSBhbmQgdGhlIHByZXZpb3VzIGhvcCAoVUFTKSwgc28gaW4g bXkgb3BpbmlvbiB0aGF0IG9ubHkgDQo+IHRhbGtzIGFib3V0IGFkamFjZW50IG5vZGVzLg0KPiAN Cj4gV2UgY2FuIG9mIGNvdXJzZSBhcmd1ZSB3aGV0aGVyIHdlIHRhbGsgYWJvdXQgbm9kZXMgYmVp bmcgDQo+IGFkamFjZW50IGR1cmluZyB0aGUgcm91dGluZyBvZiB0aGUgaW5pdGlhbCBJTlZJVEUs IG9yIG5vZGVzIA0KPiB3aGljaCBiZWNvbWUgYWRqYWNlbnQgb25jZSB0aGUgcm91dGUgc2V0IGhh cyBiZWVuIGVzdGFibGlzaGVkIDopIA0KPiANCj4gSG93ZXZlciwgSSB0aGluayB0aGUgb25seSBk aWZmZXJlbmNlIHdoaWNoIGhlYWRlcnMgd2UgdXNlIGZvciANCj4gdGhlIG5lZ290aWF0aW9uLg0K PiANCj4gSWYgd2UgdGFsayBhYm91dCBhZGphY2VudCBub2RlcyBkdXJpbmcgcm91dGluZyBvZiB0 aGUgaW5pdGlhbCANCj4gSU5WSVRFIHRoZSBWaWEgYmFzZWQgc29sdXRpb24gd29ya3MgZmluZS4N Cj4gDQo+IElmIHdlIHRhbGsgYWJvdXQgYWRqYWNlbnQgbm9kZXMgaW4gdGhlIHJvdXRlIHNldCBJ IHRoaW5rIHdlIA0KPiBuZWVkIHRvIHVzZSBlLmcuIFJlY29yZC1Sb3V0ZS9Db250YWN0L1BhdGgu DQo+IA0KPiBPZiBjb3Vyc2Ugd2UgY291bGQgdXNlIGEgVmlhIGJhc2VkIHNvbHV0aW9uIGFsc28g Zm9yIHRoZSANCj4gc2Vjb25kIGNhc2UsIGJ1dCB0aGVuIHdlIG5lZWQgdG8gZXN0YWJsaXNoIHRo ZSByb3V0ZSBzZXQgDQo+IGJlZm9yZSB3ZSBkbyB0aGUga2VlcC1hbGl2ZSBuZWdvdGlhdGlvbiwg dG8gbWFrZSBzdXJlIGFsbCANCj4gVmlhcyBiZWxvbmcgdG8gZW50aXRpZXMgaW4gdGhlIHJvdXRl IHNldC4NCj4gQW5kLCB0aGF0IGFsc28gbWVhbnMgYSBzZXBhcmF0ZSBTSVAgdHJhbnNhY3Rpb24g KFVQREFURSBvciANCj4gUFJBQ0spIGZvciB0aGUgbmVnb3RpYXRpb24gcGFydC4NCj4gDQo+IFJl Z2FyZHMsDQo+IA0KPiBDaHJpc3RlciANCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogSGlzaGFtIEtoYXJ0YWJpbCBbbWFpbHRvOmhpc2hhbS5raGFydGFi aWxAZ21haWwuY29tXQ0KPiA+IFNlbnQ6IDExLiB0b3Vrb2t1dXRhIDIwMDkgMjoyNg0KPiA+IFRv OiBDaHJpc3RlciBIb2xtYmVyZw0KPiA+IENjOiBTcGVuY2VyIERhd2tpbnM7IEVsd2VsbCwgSm9o bjsgVGFuLCBZYSBDaGluZyAoTlNOIC0gREUvTXVuaWNoKTsgDQo+ID4gU0lQQ09SRQ0KPiA+IFN1 YmplY3Q6IFJlOiBbc2lwY29yZV0gRHJhZnQgc3VibWlzc2lvbjogDQo+ID4gZHJhZnQtaWV0Zi1z aXBjb3JlLWtlZXAtMDAgKHdhc1JFOkRvY3VtZW50IEFkb3B0aW9uKQ0KPiA+IA0KPiA+IDIwMDkv NS84IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Og0K PiA+ID4NCj4gPiA+IEhpLA0KPiA+ID4NCj4gPiA+Pj4+PltKUkVdIE5vLCBJIHdvdWxkIG5vdCB3 YW50IHRvIGRvIHRoYXQuIE15IHBvaW50IGlzIHRoYXQNCj4gPiBhdCB0aGUgdGltZQ0KPiA+ID4+ Pj4+b2YgdGhlIGRpYWxvZy1mb3JtaW5nIHJlcXVlc3QsIHRoZXJlIHdpbGwgYmUgbm8gZGlyZWN0 IA0KPiB0cmFuc3BvcnQgDQo+ID4gPj4+Pj5jb25uZWN0aW9uIGJldHdlZW4gcHJveHkxIGFuZCBw cm94eTMsIHNvIGtlZXAtYWxpdmUgaXMNCj4gPiBub3QgcmVsZXZhbnQuDQo+ID4gPg0KPiA+ID4+ Pj4+SG93ZXZlciwgYXMgYSByZXN1bHQgb2YgdGhlIGZpcnN0IG1pZC1kaWFsb2cgcmVxdWVzdCwN Cj4gPiB0aGVyZSB3aWxsIGJlDQo+ID4gPj4+Pj5hIGRpcmVjdCB0cmFuc3BvcnQgY29ubmVjdGlv biBiZXR3ZWVuIFByb3h5MSBhbmQgDQo+IFByb3h5My4gU28gdGhlIA0KPiA+ID4+Pj4+cXVlc3Rp b24gaXMgd2hldGhlciB3ZSB3YW50IHRvIGZpZ3VyZSBvdXQgYSB3YXkgb2YgDQo+IGtlZXBpbmcg dGhhdCANCj4gPiA+Pj4+PmFsaXZlIG9yIG5vdC4NCj4gPiA+Pj4+DQo+ID4gPj4+PkkgdGhpbmsg dGhlcmUgd2lsbCBiZSBhIGRpcmVjdCB0cmFuc3BvcnQgY29ubmVjdGlvbiANCj4gYmV0d2VlbiBw cm94eTENCj4gPiA+IGFuZA0KPiA+ID4+Pj5wcm94eTMgYWxyZWFkeSBhdCB0aGUgdGltZSBvZiB0 aGUgcmVzcG9uc2UgdG8gdGhlIA0KPiBkaWFsb2ctZm9ybWluZyANCj4gPiA+Pj4+cmVxdWVzdC4N Cj4gPiA+Pj5bSlJFXSBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoYXQgY2FuIGhhcHBlbiwgc2lu Y2UgdGhlDQo+ID4gcmVzcG9uc2Ugd2lsbA0KPiA+ID4+PmZvbGxvdyB0aGUgcGF0aCBvZiB0aGUg VmlhIGVudHJpZXMsIG5vdCB0aGUgcGF0aCBvciANCj4gcmVjb3JkLXJvdXRlcy4NCj4gPiA+Pj5Q bGVhc2UgZXhwbGFpbi4NCj4gPiA+Pg0KPiA+ID4+SSdtIGFzIGNvbmZ1c2VkIGFzIEpvaG4gaXMu IEZvciBleGFtcGxlLCBpZiB0aGUgc2lnbmFsaW5nIHBhdGggaXMgDQo+ID4gPj51c2luZyBUQ1As IHRoZXJlIHdvdWxkIGJlIGEgVENQIGNvbm5lY3Rpb24gYmV0d2Vlbg0KPiA+ID4+UHJveHkxIGFu ZCBQcm94eTIsIGFuZCBhIHNlcGFyYXRlIFRDUCBjb25uZWN0aW9uIGJldHdlZW4NCj4gPiA+PlBy b3h5MiBhbmQgUHJveHkzLCBidXQgdGhpcyB3b3VsZCBub3QgY2F1c2UgYQ0KPiA+IFNZTi9TWU4t QUNLL0FDSyBleGNoYW5nZQ0KPiA+ID4+YmV0d2VlbiBQcm94eTEgYW5kIFByb3h5MyAtIG9yIGFt IEkgbWlzc2luZyBzb21ldGhpbmc/DQo+ID4gPg0KPiA+ID4gTm8sIHlvdSBhcmUgbm90IDopDQo+ ID4gPg0KPiA+ID4gVGhlIFRDUCBjb25uZWN0aW9uIGJldHdlZW4gUHJveHkxIGFuZCBQcm94eTMg d2lsbCBiZQ0KPiA+IGVzdGFibGlzaGVkIHdoZW4NCj4gPiA+IHNvbWV0aGluZyBpcyBzZW50IGZy b20gUHJveHkxIHRvIFByb3h5My4gVGhhdCB3b3VsZCBub3JtYWxseSBiZSBhIA0KPiA+ID4gbWlk LWRpYWxvZyByZXF1ZXN0LCBidXQgaXQgQ09VTEQgb2YgY291cnNlIGFsc28gYmUgdGhlIGtlZXAt YWxpdmUgDQo+ID4gPiBtZXNzYWdlLg0KPiA+ID4NCj4gPiA+IEJ1dCwgaWYgd2UgZG9uJ3Qgd2Fu dCB0aGUga2VlcC1hbGl2ZSBtZXNzYWdlIHRvIGVzdGFibGlzaCB0aGUgVENQIA0KPiA+ID4gY29u bmVjdGlvbiB3ZSBjYW4gc2ltcGx5IGRlY2lkZSB0aGF0IGtlZXAtYWxpdmVzIGNhbiBiZSANCj4g bmVnb3RpYXRlZCANCj4gPiA+IG9ubHkgYmV0d2VlbiBhZGphY2VudCBub2RlcywgYW5kIHdlIGNh biBrZWVwIHRoZSBWaWENCj4gPiBwYXJhbWV0ZXIgYmFzZWQNCj4gPiA+IHNvbHV0aW9uLg0KPiA+ ID4NCj4gPiA+IFRoZW4sIGl0IHdvdWxkIG5vdCBiZSBwb3NzaWJsZSB0byBuZWdvdGlhdGUga2Vl cC1hbGl2ZXMNCj4gPiBiZXR3ZWVuIFByb3h5MQ0KPiA+ID4gYW5kIFByb3h5MyBkdXJpbmcgdGhl IGluaXRpYWwgcmVxdWVzdCwgc2luY2UgUHJveHkyIHdvdWxkDQo+ID4gc3RpbGwgaW5zZXJ0DQo+ ID4gPiBhIFZpYSAoaXQgd291bGQgdGhlbiBiZSBwb3NzaWJsZSB0byBuZWdvdGlhdGUga2VlcC1h bGl2ZXMgYmV0d2Vlbg0KPiA+ID4gUHJveHkxIGFuZCBQcm94eTMgZHVyaW5nIGEgbWlkLWRpYWxv ZyByZXF1ZXN0LCBiZWN1YXNlIHRoZW4NCj4gPiB0aGV5IHdpbGwNCj4gPiA+IGJlIGFkamFjZW50 KS4NCj4gPiANCj4gPiBKb2huJ3MgcXVlcnkgaXMgbm90IGFib3V0IHRoZSBwb3NzaWJpbGl0eSBv ZiBuZWdvdGlhdGluZyANCj4ga2VlcC1hbGl2ZXMgDQo+ID4gYmV0d2VlbiBQcm94eTEgYW5kIFBy b3h5MyBkdXJpbmcgaW5pdGlhbCBtZXNzYWdlIGV4Y2hhbmdlLiBIZSBpcyANCj4gPiBhc2tpbmcg aWYgd2UgaGF2ZSBhIHJlcXVpcmVtZW50IHRvIG5lZ290aWF0ZSBrZWVwLWFsaXZlcyBiZXR3ZWVu DQo+ID4gcHJveHkxIGFuZCBwcm94eTMgdXNpbmcgbWlkLWRpYWxvZyBtZXNzYWdlcy4NCj4gPiAN Cj4gPiBJIHRoaW5rIGl0cyBhIHZhbGlkIHNjZW5hcmlvIGFuZCB3ZSBzaG91bGQgd29yayBvbiBh IHNvbHV0aW9uLg0KPiA+IA0KPiA+IEhpc2hhbQ0KPiA+IA0KPiA+ID4NCj4gPiA+IFJlZ2FyZHMs DQo+ID4gPg0KPiA+ID4gQ2hyaXN0ZXINCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gc2lwY29yZSBtYWlsaW5nIGxpc3QN Cj4gPiA+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lwY29yZQ0KPiA+ID4NCj4gPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lw Y29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cGNvcmUNCj4gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From dean.willis@softarmor.com Mon May 25 23:23:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056BD3A691A for ; Mon, 25 May 2009 23:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCHcBGskLw7p for ; Mon, 25 May 2009 23:23:01 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id F381A3A6B5F for ; Mon, 25 May 2009 23:23:00 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4Q6OJCh017409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 01:24:30 -0500 Message-Id: <8E5D6063-DA4A-4518-B4BC-338EB0B7A2CC@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 26 May 2009 01:24:12 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001DE2078@GBNTHT12009MSX.gb002.siemens.net><248CCDA78D424FD5A51EDFCDA9946E97@china.huawei.com><66cd252f0905101625nb9634b6g463a42b5469bff3e@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00(wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 06:23:08 -0000 I don't believe it is reasonable to change the keepalive set after the route-set is determined, and think it's inefficient to do an additional-re-INVITE in order to add keepalive to a dialog. So I think I prefer something on the record-route operation that lets us use the initial dialog formation to establish keepalive. -- Dean On May 25, 2009, at 12:49 AM, Christer Holmberg wrote: > > Hi, > > My proposal would be that we keep the Via based solution. > > That allows negotiation as part of of keep-alives in any > transaction. A > Record-Route based solution only allowes the negotiation during the > initial dialog transaction, since the route set can't be modified > later > during the dialog. > > Are people ok with that? > > Regards, > > Christer > > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 18. toukokuuta 2009 15:06 >> To: Hisham Khartabil >> Cc: SIPCORE >> Subject: Re: [sipcore] Draft submission: >> draft-ietf-sipcore-keep-00(wasRE:Document Adoption) >> >> >> Hi, >> >> The requirements talk about negotiating keep-alives towards >> the next hop >> (UAC) and the previous hop (UAS), so in my opinion that only >> talks about adjacent nodes. >> >> We can of course argue whether we talk about nodes being >> adjacent during the routing of the initial INVITE, or nodes >> which become adjacent once the route set has been established :) >> >> However, I think the only difference which headers we use for >> the negotiation. >> >> If we talk about adjacent nodes during routing of the initial >> INVITE the Via based solution works fine. >> >> If we talk about adjacent nodes in the route set I think we >> need to use e.g. Record-Route/Contact/Path. >> >> Of course we could use a Via based solution also for the >> second case, but then we need to establish the route set >> before we do the keep-alive negotiation, to make sure all >> Vias belong to entities in the route set. >> And, that also means a separate SIP transaction (UPDATE or >> PRACK) for the negotiation part. >> >> Regards, >> >> Christer >> >> >>> -----Original Message----- >>> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] >>> Sent: 11. toukokuuta 2009 2:26 >>> To: Christer Holmberg >>> Cc: Spencer Dawkins; Elwell, John; Tan, Ya Ching (NSN - DE/Munich); >>> SIPCORE >>> Subject: Re: [sipcore] Draft submission: >>> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) >>> >>> 2009/5/8 Christer Holmberg : >>>> >>>> Hi, >>>> >>>>>>>> [JRE] No, I would not want to do that. My point is that >>> at the time >>>>>>>> of the dialog-forming request, there will be no direct >> transport >>>>>>>> connection between proxy1 and proxy3, so keep-alive is >>> not relevant. >>>> >>>>>>>> However, as a result of the first mid-dialog request, >>> there will be >>>>>>>> a direct transport connection between Proxy1 and >> Proxy3. So the >>>>>>>> question is whether we want to figure out a way of >> keeping that >>>>>>>> alive or not. >>>>>>> >>>>>>> I think there will be a direct transport connection >> between proxy1 >>>> and >>>>>>> proxy3 already at the time of the response to the >> dialog-forming >>>>>>> request. >>>>>> [JRE] I don't understand how that can happen, since the >>> response will >>>>>> follow the path of the Via entries, not the path or >> record-routes. >>>>>> Please explain. >>>>> >>>>> I'm as confused as John is. For example, if the signaling path is >>>>> using TCP, there would be a TCP connection between >>>>> Proxy1 and Proxy2, and a separate TCP connection between >>>>> Proxy2 and Proxy3, but this would not cause a >>> SYN/SYN-ACK/ACK exchange >>>>> between Proxy1 and Proxy3 - or am I missing something? >>>> >>>> No, you are not :) >>>> >>>> The TCP connection between Proxy1 and Proxy3 will be >>> established when >>>> something is sent from Proxy1 to Proxy3. That would normally be a >>>> mid-dialog request, but it COULD of course also be the keep-alive >>>> message. >>>> >>>> But, if we don't want the keep-alive message to establish the TCP >>>> connection we can simply decide that keep-alives can be >> negotiated >>>> only between adjacent nodes, and we can keep the Via >>> parameter based >>>> solution. >>>> >>>> Then, it would not be possible to negotiate keep-alives >>> between Proxy1 >>>> and Proxy3 during the initial request, since Proxy2 would >>> still insert >>>> a Via (it would then be possible to negotiate keep-alives between >>>> Proxy1 and Proxy3 during a mid-dialog request, becuase then >>> they will >>>> be adjacent). >>> >>> John's query is not about the possibility of negotiating >> keep-alives >>> between Proxy1 and Proxy3 during initial message exchange. He is >>> asking if we have a requirement to negotiate keep-alives between >>> proxy1 and proxy3 using mid-dialog messages. >>> >>> I think its a valid scenario and we should work on a solution. >>> >>> Hisham >>> >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Tue May 26 13:07:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7283A6977 for ; Tue, 26 May 2009 13:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=1.030, BAYES_00=-2.599, GB_I_LETTER=-2, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqsQb8JcB2KQ for ; Tue, 26 May 2009 13:07:02 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 93A013A6BB2 for ; Tue, 26 May 2009 13:07:00 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n4QK8b4R057592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 15:08:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A1C4C45.90204@nostrum.com> Date: Tue, 26 May 2009 15:08:37 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dale Worley References: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 20:07:04 -0000 [as an individual] Many thanks to Dale for reviewing the document. He caught a number of legacy issues that existed in 3265 that very much deserve cleanup for a bis version, as well as a few issues with the new text. Several responses inline. Dale Worley wrote: > I'm glad we're cleaning up how we define events. But there are a few > things left to clean up: > > ** Technical > > * What is a resource? > > It looks like the draft cleans up the question of what is a resource, > in that section 3.1.2 paragraph 2 states that the request-URI > identifies the resource in question. However, given the error in the > first sentence of that paragraph (discussed below), I'd suggest > promoting the statement that the request-URI identifies the resource > to the beginning of the paragraph. > This paragraph is actually copied verbatim from section 3.1.2 of RFC 3265. > * What is state? > > There is a lot of ambiguity over what constitutes the "state" that the > event system transmits. These ambiguities bedevil attempts to > implement generic event system "toolkits" as well as complicating the > definition of new event packages. (In the call-completion committee > we've run into trouble with this.) > > In theory, we want the resource to have a certain set of state > information, and that state information progresses through a series of > different values over time. Each time the state changes, every > subscriber to that state would be notified of the new state value. We > further envision that a subscriber might supply a "filter" which is > applied to every state value; then only the output of the filter would > be sent to the subscriber, and the subscriber would be notified when > the filtered state changed. > > Layered onto this nice, clean system are a set of issues, most of > which we haven't addressed systematically: > > - If we want to be able to send state deltas, there needs to be a > defined way of taking the difference between two state values. > (This is well-described in the draft.) > > - In most event package definitions, we include the version number and > the partial/full indication *in* the state, rather than treating > them as *attributes of* the state value contained in a NOTIFY. > Since most definitions require the version number to start counting > from 0 independently for each subscription, the version number is > clearly not part of the state itself. > What you're identifying is a general philosophy that the types of state deltas that make sense are better described by the event packages themselves, instead of some generic state-delta mechanism. I'm intrigued by your proposal to add versioning information to the base specification, and would be interested in whether you have a backwards-compatible proposal for doing so. > - We haven't been clear about the difference between "state" (which > possesses values over time) and "events" (which happen instantly). > Generally, the event packages have been consistent in using state > rather than events. (E.g., the dialog package's element has > an attribute telling how a dialog entered its current state, but > that value is actually state, since it is "historical information", > a new subscriber could properly see the same value.) > > State-orientation makes implementation easier, although it has some > unspoken implications; e.g., since notifications may be missed in > some way, the subscriber may see fewer state transitions than did > thenotifier, and so the event package must be organized so that this > is not a problem. But we still have a tendency to use the word > "event" too much, even in the name of the mechanism. For instance, > in the abstract: > > The purpose of this extension is to provide an extensible framework > by which SIP nodes can request notification from remote nodes > indicating that certain events have occurred. > > Similarly, 3.2.1 says: > > NOTIFY bodies are expected to provide additional details about the > nature of the event which has occurred and the resultant resource > state. > > The essential point is that the only *events* that can be reported > are the changes in an ongoing *state value*. Though we've been > consistent about that fact, it's not clearly stated anywhere. > This reflects the evolution of the document from its original mechanism (which was, indeed, more event oriented than state oriented). I have the same model in mind as you do -- that of conveying the state of the resource. I agree that cleaning up all of the "event" language to instead talk about states and state transitions would indeed be an improvement. I'll add this to my list of changes for the next revision. > - Many event packages contain data which is expected to change > frequently, but we do not expect each change to cause sending of the > state value. For example, the dialog event package contains > "duration" elements telling how long each dialog has been > established, in seconds. Clearly, this value changes every second. > Similarly, the "reg" event package contains the CSeq value of the > most-recent registration of a contact. Changes in either of these > values are not intended to cause notification, but that is not > stated in the package definitions, nor is the possibility made clear > in the event framework. > Semantically, these are the same thing as hardwired filters on the state. Do you have any concrete suggestions for treatment of this in the base spec? Or should it simply be mentioned that some event packages inherently contain the semantic equivalent of hard-coded filters? > - In principle, the state should not be affected by who has subscribed > to received notifications for it. But there are circumstances where > we want to be aware of the set of subscribers, and to be able to > present differing information to them. The first job can probably > be done (in principle) by examining the "winfo" state, but I don't > know of a solution to the second. > You're venturing into the realm of things like the presence common policy framework, which I think cover this very well. Do you have a proposal for how to incorporate this into the base specification? > * Expiration time > > There is a problem regarding how the expiration time of a subscription > is indicated that I don't think has ever been resolved. It probably > isn't a problem in practice, but it would help if we agreed on a > solution. > > The difficulty regards how the subscriber should track the > end-of-subscription time that is established when a re-subscribe is > done. The subscriber will receive a response to its SUBSCRIBE, and > also the NOTIFY that it stimulates. It may also receive other NOTIFYs > stimulated by state changes. All of these carry expiration times, or > rather, the length of time from the present that the subscription will > last. The various NOTIFYs can be put in order by their CSeqs, and the > latest one clearly supersedes the others. But the relationship > between a received NOTIFY and a success response to a SUBSCRIBE is > harder to discern, as the subscriber does not know the order in which > they were sent, and so does not know which represents the most recent > state of the notifier. > > I think this problem is obviated by the fact that the notifier must > always send a NOTIFY after receiving any SUBSCRIBE, so that the > subscriber can in pratice disregard SUBSCRIBE responses, assuming that > the network is reliable. > > But if we take this interpretation, then the wording in the draft > should be adjusted in a number of places where it gives equal respect > to the expiration time reported in a SUBSCRIBE response and that in a > NOTIFY. > Agreed. This version of the document puts far more emphasis on NOTIFY as "the second leg in the three-way handshake." As such, I'm inclined to deprecate the conveyance of any information in SUBSCRIBE responses, and use NOTIFY requests exclusively. I'll do a pass of the document for expires use in this regard. > If we do not assume that the subscriber can reliably get a NOTIFY from > every SUBSCRIBE, then working out a reliable solution is more > difficult, due to the race condition. > > There are related problems regarding terminology. The "length of a > subscription" can mean two things, the "time from present" that it > expires, or the absolute endpoint of the subscription. The draft says > in various circumstances that a subscription cannot be lengthened > without being specific what this means. As far as I can tell: when > processing a SUBSCRIBE, a notifier must update the subscription > endpoint of the subscription so that the time from present is no > larger than what the subscriber requested (which is likely later than > the previous endpoint); a notifier may unilaterally bring sooner the > endpoint of a subscription so long as it notifies the subscriber; a > subscriber's refresh duration request is unconstrained (in that it may > require bringing forward the endpoint of the subscription, as well as > postponing it). > The rules are intended to operate exactly like expiration handling for REGISTER. Is there any language you think is particularly ambiguous? > * Notifier migration > > Notifier migration is an interesting concept and seems like it might > be very useful. Note that the preponderance of this text was copied verbatim from RFC3265, section 3.3.5. > But how does a subscriber take advantage of it? The > text in 4.4.2 assumes that the subscriber will send a new > out-of-dialog SUBSCRIBE to whatever URI it did originally. But will > that obtain an alternative notifier for the resource whose notifier > just ceased? The possibilities of SIP routing make that doubtful. > Not really. There are a couple of architectures we had in mind when we designed this mechanism: 1. The proxy/registrar has a "default" destination that it will send SUBSCRIBE requests to when a user has no registered UAs. This "default" destination could serve proper state for the corresponding resource (or even act as a simple "parking lot", from which subscribers will be migrated once the watched user has a UA registered). 2. The notifier is part of a cluster of notifiers that can all service requests corresponding to the user. In order to take the notifier offline, it informs its clustering mechanism that it is no longer accepting new traffic, and then sends NOTIFY messages to each subscribed UA for the purpose of moving them to a notifier that is not going offline. Once all such subscriptions are shed, the node can be taken out of service. A similar mechanism can be used to rebalance subscriptions after adding notifiers to a cluster. In any case, it's not the subscriber taking advantage of this mechanism; it's the notifier. > What we want is for the notifier to give the subscriber a > globally-routable URI that will reach an alternative notifier, but > there seems to be no mechanism to carry the URI. > At the risk of triggering your "REFER means everything" rant, I think this kind of operation would best be served by using REFER to initiate the equivalent of a "blind transfer" of the subscription. This looks a lot like figure 1 of draft-ietf-sipping-cc-transfer-12 (except with "SUBSCRIBE" instead of "INVITE"). > ** Editorial > > * section 2 > > The definition of "subscription" doesn't mention that the existence of > a subscription means that the notifier will send state updates to the > subscriber. > Good point. > * section 3.1 > > This paragraph should say something like "The SUBSCRIBE method is used > to requrest the creation of a subscription which will send current > state and state updates from a remote node." > Yes, that's more explicit. > * section 3.1.2 > > The Request URI of a SUBSCRIBE request, most importantly, contains > enough information to route the request to the appropriate entity per > the request routing procedures outlined in SIP [RFC3261]. > > This is not necessarily true -- the routing is also affected by any > Route headers in the request. In sipX, we use that feature so that we > can present to the notifier a resource name (request-URI) that need > not be the same as the SIP URI of the notifier. > Would "The Request URI of a SUBSCRIBE request, in conjunction its Route header fields, contains enough information..." satisfy your concern? > * section 4.1.3 > > NOTIFY requests MUST contain "Subscription-State" header fields which > indicate the status of the subscription. > > This is an instance where plurals should be made singular for clarity: > > A NOTIFY request MUST contain a "Subscription-State" header field > which indicates the status of the subscription. > Agreed. > * section 4.1.3 > > giveup: The subscription has been terminated because the notifier > could not obtain authorization in a timely fashion. If a "retry- > after" parameter is also present, the client SHOULD wait at least > the number of seconds specified by that parameter before > attempting to re-subscribe; otherwise, the client MAY retry > immediately, but will likely get put back into pending state. > > The last clause would read better as: > > the client MAY retry immediately, although the new subscription will > likely go into the pending state. > > The subscription doesn't really "get put back" into pending, since it > is now in terminated. > That's a reasonable clarification. > * section 4.2.1.2 > > Note that a NOTIFY message is always sent immediately after any 200- > class response to a SUBSCRIBE request, regardless of whether the > subscription has already been authorized. > > Perhaps it is better to say: > > Note that a NOTIFY message is always sent immediately after any > 200-class response to a SUBSCRIBE request, regardless of the state > of the created subscription (e.g., pending). > Okay. > * section 4.2.1.4. Refreshing of Subscriptions > > When a notifier receives a subscription refresh, assuming that the > subscriber is still authorized, the notifier updates the expiration > time for subscription. As with the initial subscription, the server > MAY shorten the amount of time until expiration, but MUST NOT > increase it. > > Here is one of the places where the discussion of "shortening > expiration time" is ambiguous. Reading it literally, it means that > the notifier cannot increase the absolute expiration time *relative to > what it was before the SUBSCRIBE arrived*, as "the amount of time > until expiration" is an attribute of the subscription. Of course, > what is meant, the notifier sets a new expiration time which may be no > longer-from-present that the duration requested in the SUBSCRIBE. > I'll see if I can adapt some language from 3261 regarding REGISTER handling to make this clearer. > * section 4.4.1 > > NOTIFY requests are matched to such SUBSCRIBE requests if they > contain the same "Call-ID", a "To" header field "tag" parameter which > matches the "From" header field "tag" parameter of the SUBSCRIBE, and > the same "Event" header field. Rules for comparisons of the "Event" > header fields are described in Section 8.2.1. > > This is awkward. How about: > > NOTIFY and SUBSCRIBE requests are within the same subscription > usage if they contain the same "Call-ID", a "To" header field "tag" > parameter which matches the "From" header field "tag" parameter of > the SUBSCRIBE, and the same "Event" header field. Rules for > comparisons of the "Event" header fields are described in Section > 8.2.1. > Actually, I think this would be best served by recasting the association as it relates to 3261 dialogs, and then adding on the "Event" matching. I'll see if I can come up with something reasonable that conveys enough information. > * section 4.4.2. > > Notifier migration is an interesting concept. But note that the text > is incorrect: > > Upon receipt of this NOTIFY message, the subscriber SHOULD attempt to > re-subscribe (as described in the preceding sections). Note that > this subscription is established on a new dialog, and does not re-use > the route set from the previous subscription dialog. > > It's not correct to say the subscriber is "re-subscribing" (in the > sense of the draft). I can see your point. I'll change it to something like "initate a new subscription to the resource." > There is also the technical question of what > request-URI the subscriber should use to re-subscribe. (see above) > I think the intention was always that the subscriber would use the same Request-URI (and, if relevant, Route) that was used to set up the subscription that has just terminated. I'll clarify this point. > * section 4.5.1 > > Because GRUUs are guaranteed to route to a *** a specific device, this > > Contains duplicate word "a". > I'll fix that. > * section 5.1 > > When designing an event package using the methods described in this > document for event notification, it is important to consider: is SIP > an appropriate mechanism for the problem set? Is SIP being selected > > The initial "is" of the clauses are not consistently capitalized. > This issue isn't as simple as it appears at first. See, for example, . If I changed it to a capital letter, there's a good chance that I'd get a request to change it back from someone who has a different sense of aesthetics than you do (and I believe that there's a strong argument to be made that the form in the current document is the more common form for both American and British English). I've had to mediate these kinds of disputes before, and was kind of hoping to avoid them this time -- in particular, I don't want to have to add another paragraph like the final paragraph of section 1.2 to clarify how I have chosen to treat colons and capitalization. So, unless there is an argument that can be made regarding clarity, I'm not accepting comments on the topic of typographical conventions. :) > * section 5.3 > > Any event package that supports delta changes to states MUST include > a version number that increases by exactly one for each NOTIFY > transaction in a subscription. > > And it must include a full/partial state indicator. > Good point. > * section 5.4 > > Event packages are not required to reiterate any of the behavior > described in this document, although they may choose to do so for > clarity or emphasis. In general, though, such packages are expected > to describe only the behavior that extends or modifies the behavior > described in this document. > > This reads strangely, as it suggests that an event package description > might contradict the RFC. > We certainly can't prevent it. :) Examples of where this happens include filtering and throttling, which do actually change things like when NOTIFY messages are sent. 3265bis (and 3265) say this happens when the state changes. The throttling document says this happens when the state changes and/or when other criteria are met. > * sectin 5.4.3 > > It is expected that most, but not all, event packages will define > syntax and semantics for SUBSCRIBE method bodies; > > This reads strangely, since only one defined event package has > SUBSCRIBE bodies. > I think we optimistically believed that people would define filters along with their event packages, instead of choosing to bolt them on later. But your observation that this didn't play out the way we expected is a good one, and I'll revise the text accordingly. > * section 5.4.7 > > and whether state information is complete or deltas for > notifications > > This is awkwardly phrased. Perhaps end the sentence before this > clause and continue: > > It also includes whether state deltas can be used, and if so, how they > are interpreted by the subscriber to update its record of the state; > see Section 5.3. > Okay. > * section 7 > > The IANA Considerations section does not name the new SUBSCRIBE and > NOTIFY methods, which is needs to do in order to register the methods. > (RFC 3265 doesn't do this either, although the IANA database > entries for SUBSCRIBE and NOTIFY references RFC 3265.) > I have an open action item to figure out how the IESG wants us to handle IANA registration sections of bis RFCs. But this is a good catch, and one that I don't recall being pointed out before. I'll make a note of it, with action pending on the final guidance I get regarding IANA sections in bis docments. /a From dean.willis@softarmor.com Tue May 26 17:44:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 652EC3A70A2 for ; Tue, 26 May 2009 17:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgJKvjubIJ3T for ; Tue, 26 May 2009 17:44:55 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 807593A6CD6 for ; Tue, 26 May 2009 17:44:55 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4R0kERQ026594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 26 May 2009 19:46:15 -0500 Message-Id: <9FB03C60-0484-49DC-BC33-96057B6172D6@softarmor.com> From: Dean Willis To: SIPCORE Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 26 May 2009 19:46:09 -0500 References: <20090526143401.5D12028C2BD@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) Subject: [sipcore] Fwd: [Sip] Last Call: draft-ietf-sip-connect-reuse (Connection Reuse in the Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 00:44:56 -0000 Please follow this discussion on the SIP list. Begin forwarded message: > From: The IESG > Date: May 26, 2009 9:34:01 AM CDT > To: IETF-Announce > Cc: sip@ietf.org > Subject: [Sip] Last Call: draft-ietf-sip-connect-reuse (Connection > Reuse in the Session Initiation Protocol (SIP)) to Proposed Standard > Reply-To: ietf@ietf.org > > The IESG has received a request from the Session Initiation Protocol > WG > (sip) to consider the following document: > > - 'Connection Reuse in 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 substantive comments to > the > ietf@ietf.org mailing lists by 2009-06-09. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect- > reuse-13.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10776&rfc_flag=0 > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From dean.willis@softarmor.com Tue May 26 17:45:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261663A6F74 for ; Tue, 26 May 2009 17:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruxuLVX4bPfE for ; Tue, 26 May 2009 17:45:43 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1DA8A3A6867 for ; Tue, 26 May 2009 17:45:43 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4R0kERR026594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 26 May 2009 19:46:54 -0500 Message-Id: <16BBAF22-0ACC-44A1-94EB-78C3047EB144@softarmor.com> From: Dean Willis To: SIPCORE Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 26 May 2009 19:46:53 -0500 References: <656509D0-269E-48C4-BA76-0195E1A31B3C@softarmor.com> X-Mailer: Apple Mail (2.935.3) Subject: [sipcore] Fwd: [Sip] Draft ietf-sip-xcapevent revised, many open questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 00:45:44 -0000 Please follow this discussion on the SIP list. Begin forwarded message: > From: Dean Willis > Date: May 26, 2009 7:35:21 PM CDT > To: "sip@ietf.org List" > Cc: Robert Sparks > Subject: [Sip] Draft ietf-sip-xcapevent revised, many open questions > > > I have submitted a revised version of the XCAP Event draft based on > feedback from Lisa Dusseault and that incorporates a vast amount of > editing by Jean Mahoney, a technical writer who volunteered to help > clean things up after Lisa pushed the draft back from IESG review. > > > > See: > http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-05.txt > > and since tehre are a lot of changes, the side-by-side diff is > really helpful: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-sip-xcapevent-05 > > There are a number of questions open in the existing document. > > > > 1) What's the default notification mode supposed to be? "xml- > patching" is listed as the default and fail-safe in some text, but > "no-patching" is also described as the singular "must implement" > mode. It seems to me that if a mode is the default if no mode is > specified, then that mode had better be the default. > This question is a primary source of confusion in Section 4.3, and > I'd appreciate some feedback. This whole section got a lot of edits, > you may want to usea difftool. > > > 2) Aggregating definition > > Our current text has this definition; is it right? > > Aggregating: An XCAP client can update only a single XCAP Component > at a time using HTTP. However, a notifier may be able to > aggregate a series of these modifications into a single > notification using XML-Patch- Ops semantics encoded in the XCAP- > Diff format. > > > > 3) SUBSCRIBE bodies > > Section 4.4 currently says; > > The SUBSCRIBE request MAY contain an Accept header field. If no > such > header field is present, it has a default value of "application/ > xcap-diff+xml". If the header field is present, it MUST include > "application/xcap-diff+xml", and MAY include any other types. > > This doesn't sound right to me. > > > > 4) Error recovery > > Section 4.7 says: > > While the "aggregate" mode uses bandwidth most efficiently, it > introduces other challenges. The initial synchronization might fail > with rapidly changing resources, because the "aggregate" mode > messages might not include the full version-history of a document > and > the base XCAP protocol does not support version-history retrievals > of > documents. When new documents are created in subscribed collections > and the notifier is aggregating patches, the same issue can occur. > In a corner case, the notifier may not be able to provide patches > with the XML-Patch-Ops [RFC5261] semantics. Therefore, if the > notifier has to temporarily disable diff generation and send only > the > URI references of some changed documents to the subscriber, it MUST > continue with the "xcap-patching" mode afterwards for these > resources, if the initial subscription also started with the "xcap- > patching" mode. Recovery from this error condition therefore means > that the subscriber must refresh to a "known good" state by > downloading the current document if it has lost track of the > patching > operations as indicated by mismatching ETags., > > (note the accidental extra comma here at the end, I just noticed it, > and it is my fault). > > Anyhow, does the "recovery" text make sense? > > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From gonzalo.camarillo@ericsson.com Wed May 27 04:12:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA8B3A6C58 for ; Wed, 27 May 2009 04:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.461 X-Spam-Level: X-Spam-Status: No, score=-5.461 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msm371fi6JJo for ; Wed, 27 May 2009 04:12:11 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 12D7A3A696F for ; Wed, 27 May 2009 04:12:10 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-16-4a1d2004f334 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 6B.6A.30868.4002D1A4; Wed, 27 May 2009 13:12:05 +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, 27 May 2009 13:12:04 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 13:12:04 +0200 Message-ID: <4A1D2004.9020705@ericsson.com> Date: Wed, 27 May 2009 14:12:04 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2009 11:12:04.0317 (UTC) FILETIME=[F72138D0:01C9DEBB] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Status of the 199 draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 11:12:12 -0000 Folks, as you know, the 199 draft, whose current version can be found below, was WGLCed in the SIP WG a few months ago: http://www.ietf.org/mail-archive/web/sip/current/msg25440.html http://tools.ietf.org/id/draft-ietf-sipcore-199-00.txt We intend to request its publication as soon as the author of the draft addresses all the comments received so far. Therefore, if you want to send comments on this draft, do it fast. Cheers, Gonzalo SIPCORE co-chair From gonzalo.camarillo@ericsson.com Wed May 27 05:30:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24543A7110; Wed, 27 May 2009 05:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyLAhkMsHY9Q; Wed, 27 May 2009 05:30:39 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 068AB3A711B; Wed, 27 May 2009 05:30:37 -0700 (PDT) X-AuditID: c1b4fb3c-b7b28ae000005484-8c-4a1d32cc95c7 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7C.86.21636.CC23D1A4; Wed, 27 May 2009 14:32:14 +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, 27 May 2009 14:32:12 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 14:32:12 +0200 Message-ID: <4A1D32CC.5070908@ericsson.com> Date: Wed, 27 May 2009 15:32:12 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Internet-Drafts@ietf.org References: <20090420194501.9B4C73A6C6F@core3.amsl.com> In-Reply-To: <20090420194501.9B4C73A6C6F@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2009 12:32:12.0194 (UTC) FILETIME=[28D90820:01C9DEC7] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-presence-scaling-requirements-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 12:30:40 -0000 Folks, this draft was WGLCed in SIPPING some time ago: http://www.ietf.org/mail-archive/web/sipping/current/msg16089.html We intend to request its publication as soon as all the dedicated reviewers give their OK. So, if you have comments on this draft, send them to the list as soon as possible. Thanks, Gonzalo SIPCORE co-chair Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > > Title : Scaling Requirements for Presence in SIP/SIMPLE > Author(s) : A. Houri, et al. > Filename : draft-ietf-sipcore-presence-scaling-requirements-00.txt > Pages : 9 > Date : 2009-04-20 > > The document provides a set of requirements for enabling interdomain > scaling in presence for SIP/SIMPLE. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-presence-scaling-requirements-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Wed May 27 05:47:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F40A3A70B2 for ; Wed, 27 May 2009 05:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.474 X-Spam-Level: X-Spam-Status: No, score=-5.474 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HghSUXvVEpyY for ; Wed, 27 May 2009 05:47:26 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AA8A13A6D8B for ; Wed, 27 May 2009 05:45:47 -0700 (PDT) X-AuditID: c1b4fb3c-b7b28ae000005484-57-4a1d360e753e Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 47.68.21636.E063D1A4; Wed, 27 May 2009 14:46:07 +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, 27 May 2009 14:46:06 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 14:46:06 +0200 Message-ID: <4A1D360E.7000505@ericsson.com> Date: Wed, 27 May 2009 15:46:06 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <49FA1267.5040204@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DF9B@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15C3@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE15D2@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1785@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001DE1AD4@GBNTHT12009MSX.gb002.siemens.net> <0D5F 89FAC29E2C41B98A6A762007F5D001DE1B12@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2009 12:46:06.0303 (UTC) FILETIME=[1A03F6F0:01C9DEC9] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 12:47:27 -0000 Hi, > UA1 -> Proxy1 - >Proxy2 -> Proxy3 -> UA2 John wrote: >> [JRE] No, I would not want to do that. My point is that at >> the time of the dialog-forming request, there will be no >> direct transport connection between proxy1 and proxy3, so >> keep-alive is not relevant. However, as a result of the first >> mid-dialog request, there will be a direct transport >> connection between Proxy1 and Proxy3. So the question is >> whether we want to figure out a way of keeping that alive or not. Christer answered: > I think there will be a direct transport connection between proxy1 and > proxy3 already at the time of the response to the dialog-forming > request. So, you can start sending keep-alives at that point. You don't > need to wait for the first mid-dialog request. the response will not trigger such a connection because even though Proxy2 did not record routed, he inserted itself in the Via, which is used to route responses. On a different note, the negotiation you are trying to perform here has somewhat similar requirements as the one specified in RFC 3486. You may want to have a look at that spec at some point. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Wed May 27 05:49:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 643413A70BA for ; Wed, 27 May 2009 05:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.48 X-Spam-Level: X-Spam-Status: No, score=-5.48 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxrEpu7ygpeF for ; Wed, 27 May 2009 05:49:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3653B3A6E2C for ; Wed, 27 May 2009 05:49:49 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-e3-4a1d3717b2cc Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 60.78.30868.6173D1A4; Wed, 27 May 2009 14:50:31 +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, 27 May 2009 14:50:28 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 14:50:28 +0200 Message-ID: <4A1D3714.1010607@ericsson.com> Date: Wed, 27 May 2009 15:50:28 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <0D5F89FAC29E2C41B98A6A762007F5D001DE2078@GBNTHT12009MSX.gb002.siemens.net> <248CCDA78D424FD5A51EDFCDA9946E97@china.huawei.com> <66cd252f0905101625nb9634b6g463a42b5469bff3e@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2009 12:50:28.0690 (UTC) FILETIME=[B6690B20:01C9DEC9] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (wasRE:Document Adoption) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 12:49:51 -0000 Hi, > We can of course argue whether we talk about nodes being adjacent during > the routing of the initial INVITE, or nodes which become adjacent once > the route set has been established :) well, that is actually the main point of the discussion. We need to understand whether or not we have that requirement. For example, in RFC 3486, the UAC can negotiate SigComp compression with a node that will be adjacent to it during the dialog but that was not in the initial request. Do we have the same requirement here or not? Cheers, Gonzalo From salvatore.loreto@ericsson.com Wed May 27 06:51:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005B23A6D01 for ; Wed, 27 May 2009 06:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9sXXTy+cFco for ; Wed, 27 May 2009 06:51:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C9D733A6965 for ; Wed, 27 May 2009 06:51:26 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-6f-4a1d456c2098 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 0D.00.30868.C654D1A4; Wed, 27 May 2009 15:51:40 +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, 27 May 2009 15:51:40 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 15:51:39 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CC55224D6; Wed, 27 May 2009 16:51:39 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 94BED219F7; Wed, 27 May 2009 16:51:39 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2C2F8219CD; Wed, 27 May 2009 16:51:39 +0300 (EEST) Message-ID: <4A1D456A.6080901@ericsson.com> Date: Wed, 27 May 2009 16:51:38 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Adam Roach References: <4A15DB15.8020901@nostrum.com> In-Reply-To: <4A15DB15.8020901@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 27 May 2009 13:51:40.0004 (UTC) FILETIME=[42AF1A40:01C9DED2] X-Brightmail-Tracker: AAAAAA== Cc: Avshalom Houri , Jonathan Rosenberg , SIPCORE Subject: Re: [sipcore] [Fwd: Re: I-D Action:draft-ietf-sipcore-subnot-etags-02.txt] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 13:51:28 -0000 Hi there, I have carefully read the last version of the draft and I don't have any comments to add. I believe it is ready for publication! /Sal From wangxiangjun@huawei.com Sat May 30 18:24:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B5228C11F for ; Sat, 30 May 2009 18:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.297 X-Spam-Level: *** X-Spam-Status: No, score=3.297 tagged_above=-999 required=5 tests=[AWL=-2.243, BAYES_50=0.001, EXTRA_MPART_TYPE=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MY_CID_AND_STYLE=1.54, RDNS_NONE=0.1, T_TVD_FW_GRAPHIC_ID1=0.01] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmqBxtbWFzS8 for ; Sat, 30 May 2009 18:24:30 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id D83713A6A7E for ; Sat, 30 May 2009 18:24:29 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKH000HFINGU7@szxga03-in.huawei.com> for sipcore@ietf.org; Sun, 31 May 2009 09:26:04 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKH00M3WINGU0@szxga03-in.huawei.com> for sipcore@ietf.org; Sun, 31 May 2009 09:26:04 +0800 (CST) Received: from w00138473 ([10.85.28.186]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKH00H8CINFIY@szxml06-in.huawei.com> for sipcore@ietf.org; Sun, 31 May 2009 09:26:04 +0800 (CST) Date: Sun, 31 May 2009 09:26:04 +0800 From: wang xiangjun To: Adam Roach Message-id: <012901c9e18e$c3bdc7d0$ba1c550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/related; boundary="Boundary_(ID_1dO9rlzVpG/ykNpS8ns4pA)"; type="multipart/alternative" X-Priority: 3 X-MSMail-priority: Normal References: <49EF423D.3080700@nostrum.com> Cc: SIPCORE Subject: Re: [sipcore] Forking and draft-ietf-sipcore-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 01:24:31 -0000 This is a multi-part message in MIME format. --Boundary_(ID_1dO9rlzVpG/ykNpS8ns4pA) Content-type: multipart/alternative; boundary="Boundary_(ID_smwre5R14G8IJkU+PM58mA)" --Boundary_(ID_smwre5R14G8IJkU+PM58mA) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 SGVsbG8gQWRhbSwNCiAgIEkgaGF2ZSByZWFkIHRoZSBkcmFmdCBhbmQgeW91ciBjbGFyaWZpY2F0 aW9uIGFib3V0IHRoZSBmb3JraW5nIHNpdHVhdGlvbiB3aGljaCBpcyBhIGdvb2Qgam9iLCBidXQg SSBzdGlsbCBoYXZlIGEgcHJvYmxlbSBhYm91dCBpdCBhcyBiZWxvdzoNCiAgIElmIGEgc3Vic2Ny aWJlciBzZW5kcyBhIFNVQlNDUklCRSByZXF1ZXN0IGFuZCB0aGUgcmVxdWVzdCBpcyBmb3JrZWQg dG8gdHdvIG5vdGlmaWVycyBieSBhIHByb3h5IHdoaWNoIGVzdGFibGlzaGVzIHR3byBkaWFsb2dz LiBUaGUgc3Vic2NyaWJlciB3aWxsIHJlY2VpdmUgdHdvIFNJUC1FdGFnIGZyb20gdGhlIHR3byBu b3RpZmllcnMgcmVzcGVjdGl2ZWx5LCBpcyBpdCByaWdodD8gVGhlbiB0aGUgc3Vic2NyaXB0aW9u IHRlcm1pbmF0ZXMgYW5kIGFmdGVyIGEgd2hpbGUgdGhlIHN1YnNjcmliZXIgd2FudHMgdG8gcmVz dW1lIGEgc3Vic2NyaXB0aW9uLCB0aGUgcHJvYmxlbSBpcyBob3cgZG9lcyB0aGUgc3Vic2NyaWJl ciBkZWFscyB3aXRoIHRoZSBTdXBwcmVzcy1JZi1NYXRjaCBoZWFkZXIgZmllbGQ/IERvZXMgaXQg aW5jbHVkZSBvbmUgb2YgdGhlIFNJUC1FdGFnIHZhbHVlIG9yIGJvdGggb2YgdGhlbT8NCg0KQmVz dCBSZWdhcmRzLA0KDQoNCndhbmd4aWFuZ2p1bg0K5Y2O5Li65oqA5pyv5pyJ6ZmQ5YWs5Y+4ICAN Cg0KDQrlnLDlnYDvvJrmt7HlnLPluILpvpnlspfljLrlnYLnlLDljY7kuLrln7rlnLAg6YKu57yW 77yaNTE4MTI5DQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCuac rOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7 hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOA guemgQ0K5q2i5Lu75L2V5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/55So77yI5YyF5ous5L2G 5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi244CB5oiW5pWj5Y+R77yJ 5pys6YKu5Lu25LitDQrnmoTkv6Hmga/jgILlpoLmnpzmgqjplJnmlLbkuobmnKzpgq7ku7bvvIzo r7fmgqjnq4vljbPnlLXor53miJbpgq7ku7bpgJrnn6Xlj5Hku7bkurrlubbliKDpmaTmnKzpgq7k u7bvvIENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIA0KaXMgaW50ZW5kZWQgb25seSBmb3Ig dGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1 c2Ugb2YgdGhlIA0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNs dWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCANCmRpc2Nsb3N1cmUs IHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRo ZSBpbnRlbmRlZCANCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0 aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IA0KcGhvbmUg b3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0KICAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBBZGFtIFJvYWNoIA0KICBUbzogU0lQQ09SRSANCiAgU2Vu dDogVGh1cnNkYXksIEFwcmlsIDIzLCAyMDA5IDEyOjEzIEFNDQogIFN1YmplY3Q6IFtzaXBjb3Jl XSBGb3JraW5nIGFuZCBkcmFmdC1pZXRmLXNpcGNvcmUtc3Vibm90LWV0YWdzDQoNCg0KICBbYXMg YW4gaW5kaXZpZHVhbCBwYXJ0aWNpcGFudF0NCg0KICBZb3UndmUgcHJvYmFibHkgbm90aWNlZCBh IG5ldyB2ZXJzaW9uIG9mIHRoZSBzdWJub3QtZXRhZ3MgZG9jdW1lbnQganVzdCANCiAgY2FtZSBv dXQuIFRoaXMgdmVyc2lvbiBpbmNvcnBvcmF0ZXMgc29tZSBjaGFuZ2VzIHRvIHJlc29sdmUgYSAN CiAgbGFzdC1taW51dGUgdGVjaG5pY2FsIGlzc3VlIHdpdGggdGhlIHdheSB0aGlzIGRvY3VtZW50 IGludGVyYWN0cyB3aXRoIA0KICByZXF1ZXN0IGZvcmtpbmcuIChUaGVyZSdzIGFsc28gYW4gQUJO RiBjaGFuZ2UsIGJ1dCB0aGVyZSdzIGEgc2VwYXJhdGUgDQogIHRocmVhZCBnb2luZyBvbiB0aGF0 IHRvcGljKS4NCg0KICBJbiBwcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGUgZG9jdW1lbnQsIHRoZSBs YW5ndWFnZSBhbGxvd2VkIGNvbXBsZXRlIA0KICBzdXBwcmVzc2lvbiBvZiBOT1RJRlkgbWVzc2Fn ZXMgZXhjZXB0IHdoZW4gdGhlcmUgd2VyZSAicmVwb3J0YWJsZSANCiAgY2hhbmdlcyBpbiB0aGUg Tk9USUZZIGhlYWRlciIuIFRoaXMgY3JpdGVyaWEgd2FzIHNvbWV3aGF0IGFtYmlndW91cyBpbiAN CiAgdGhlIGdlbmVyYWwgY2FzZSBvZiBlc3RhYmxpc2hpbmcgYSBuZXcgc3Vic2NyaXB0aW9uICh0 aGUgdHJhbnNpdGlvbiBvZiANCiAgc3Vic2NyaXB0aW9uIHN0YXRlIHRvICJhY3RpdmUiIHRlY2hu aWNhbGx5IHF1YWxpZmllcyBhcyBhICJyZXBvcnRhYmxlIA0KICBjaGFuZ2UgaW4gdGhlIE5PVElG WSBoZWFkZXIiLCBidXQgaW1wbGVtZW50b3JzIHdlcmUgbGVmdCB0byBmaWd1cmUgdGhpcyANCiAg b3V0IGluZGVwZW5kZW50bHkpLiBUbyBjb21wbGljYXRlIG1hdHRlcnMsIHRoZXJlIHdlcmUgYXQg bGVhc3QgdHdvIA0KICBwYXNzYWdlcyBpbiB0aGUgZG9jdW1lbnQgdGhhdCBzdHJvbmdseSBzdWdn ZXN0ZWQgdGhhdCB0aGVyZSBtYXkgYmUgDQogIGNpcmN1bXN0YW5jZXMgaW4gd2hpY2ggdGhlIGZp cnN0IE5PVElGWSBpbiBhIHN1YnNjcmlwdGlvbiB3b3VsZCBiZSANCiAgY29tcGxldGVseSBzdXBw cmVzc2VkLCB3aGljaCBjYXVzZXMgc29tZSBzZXJpb3VzIGlzc3VlcyB3aXRoIGZvcmtpbmcuDQoN CiAgVGhlIGNvbXBsZXRlIHN1cHByZXNzaW9uIG9mIE5PVElGWSBtZXNzYWdlcyB3YXMgYWxzbyBl eHBsaWNpdCBmb3IgDQogIHJlc291cmNlIHN0YXRlIHBvbGxpbmcsIHdoaWNoIGdpdmVzIHJpc2Ug dG8gc2ltaWxhciBpc3N1ZXMuDQoNCiAgVGhlIGlzc3VlIHdpdGggc3VwcHJlc3NpbmcgdGhlIGZp cnN0IE5PVElGWSBtZXNzYWdlIGluIGEgZGlhbG9nIGlzIHRoYXQgDQogIGEgZm9ya2VkIFNVQlND UklCRSBtZXNzYWdlIGNhbiBsYW5kIG9uIHNldmVyYWwgbm90aWZpZXJzLCBlYWNoIG9mIHdob20g DQogIG1heSB3ZWxsIGFjY2VwdCB0aGUgc3Vic2NyaXB0aW9uLiBIb3dldmVyLCBkdWUgdG8gU0lQ IGZvcmtpbmcgDQogIHByb2Nlc3NpbmcsIG9ubHkgb25lIGZpbmFsIHJlc3BvbnNlIHRvIHRoZSBT VUJTQ1JJQkUgd2lsbCBhcnJpdmUgYXQgdGhlIA0KICBzdWJzY3JpYmVyLg0KDQogIFVuZGVyIHRo ZSAzMjY1IG1vZGVsLCB0aGlzIGlzIHJlc29sdmVkIGJ5IHRoZSB1c2Ugb2YgYW4gaW1tZWRpYXRl IE5PVElGWSANCiAgaW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uIC0tIHRoZSBzdWJzY3JpYmVyIGxl YXJucyBhYm91dCBhbGwgdGhlIA0KICByZXN1bHRpbmcgc3Vic2NyaXB0aW9ucyBiZWNhdXNlIGl0 IHJlY2VpdmVzIGEgTk9USUZZIG1lc3NhZ2UgZm9yIGVhY2ggDQogIG9uZS4gUmVtb3ZpbmcgdGhp cyBhc3BlY3Qgb2Ygc3Vic2NyaXB0aW9uIGVzdGFibGlzaG1lbnQgYmFzaWNhbGx5IA0KICByZS1j cmVhdGVzIGEgdmFyaWFudCBvZiB0aGUgSEVSRlAgcHJvYmxlbSwgZXhjZXB0IG11Y2ggd29yc2U6 IGluc3RlYWQgb2YgDQogIGZhaWxpbmcgdG8gbGVhcm4gYWJvdXQgdmFyaW91cyByZXF1ZXN0IGZh aWx1cmVzLCB0aGUgc3Vic2NyaWJlciBmYWlscyB0byANCiAgbGVhcm4gYWJvdXQgdmFyaW91cyBz dWNjZXNzZnVsIGRpYWxvZyBlc3RhYmxpc2htZW50cy4NCg0KICBUaGUgbW9zdCByZWNlbnQgdmVy c2lvbiBvZiB0aGUgZG9jdW1lbnQgYWRkcmVzc2VzIHRoaXMgYnk6DQoNCiAgICAgMS4gQ2xlYW5p bmcgdXAgdGhlIHBhc3NhZ2VzIHRoYXQgaW1wbGllZCBzdXBwcmVzc2lvbiBvZiB0aGUgaW5pdGlh bA0KICAgICAgICBOT1RJRlkgbWVzc2FnZSBpbiBhIGRpYWxvZw0KDQogICAgIDIuIE1ha2luZyBl eHBsaWNpdCB0aGUgcHJldmlvdXNseSBpbXBsaWNpdCBiZWhhdmlvciBvZiBub3QNCiAgICAgICAg c3VwcHJlc3NpbmcgaW5pdGlhbCBOT1RJRlkgbWVzc2FnZSBpbiBhIGRpYWxvZw0KDQogICAgIDMu IENoYW5naW5nIHBvbGwgYmVoYXZpb3IgdG8gcmVxdWlyZSBlbXB0eSBOT1RJRlkgbWVzc2FnZXMg aW5zdGVhZCBvZg0KICAgICAgICBjb21wbGV0ZWx5IHN1cHByZXNzZWQgTk9USUZZIG1lc3NhZ2Vz DQoNCiAgT25seSB0aGUgdGhpcmQgY2hhbmdlIGlzIGFuIGFjdHVhbCBjaGFuZ2UgaW4gYmVoYXZp b3IuIFRoZSBmaXJzdCB0d28gYXJlIA0KICBzaW1wbHkgbWFraW5nIHByZXZpb3VzbHkgaW1wbGll ZCBiZWhhdmlvciBleHBsaWNpdC4NCg0KICBJIHJlYWxpemUgdGhhdCB0aGlzIGlzIGEgYml0IG9m IGRlZXAgUkZDIDMyNjUgYXJjYW5hLCBidXQgcGxlYXNlIHdlaWdoIA0KICBpbiBvbiB0aGUgY2hh bmdlcyBzbyB3ZSBjYW4gbW92ZSB0aGUgZG9jdW1lbnQgb3ZlciB0aGUgZmluaXNoIGxpbmUgc29v bi4gDQogIFRoYW5rcyENCg0KICAvYQ0KICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICBzaXBjb3JlIG1haWxpbmcgbGlzdA0KICBzaXBjb3JlQGlldGYu b3JnDQogIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ== --Boundary_(ID_smwre5R14G8IJkU+PM58mA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzUyNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZM+SGVsbG8gQWRh bSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TPiZuYnNwOyZuYnNwOyBJIGhh dmUgcmVhZCB0aGUgZHJhZnQgYW5kIHlvdXIgY2xhcmlmaWNhdGlvbiANCmFib3V0IHRoZSBmb3Jr aW5nIHNpdHVhdGlvbiZuYnNwO3doaWNoIGlzIGEgZ29vZCBqb2IsIGJ1dCBJIHN0aWxsIGhhdmUm bmJzcDthIA0KcHJvYmxlbSBhYm91dCBpdCBhcyBiZWxvdzo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U95a6L5L2TPiZuYnNwOyZuYnNwOyBJZiBhIHN1YnNjcmliZXIgc2VuZHMgYSBTVUJT Q1JJQkUgcmVxdWVzdCBhbmQgDQp0aGUgcmVxdWVzdCBpcyBmb3JrZWQgdG8gdHdvIG5vdGlmaWVy cyBieSBhIHByb3h5IHdoaWNoJm5ic3A7ZXN0YWJsaXNoZXMgdHdvIA0KZGlhbG9ncy4gVGhlIHN1 YnNjcmliZXIgd2lsbCByZWNlaXZlIHR3byBTSVAtRXRhZyBmcm9tIHRoZSB0d28gbm90aWZpZXJz IA0KcmVzcGVjdGl2ZWx5LCBpcyBpdCByaWdodD8gVGhlbiB0aGUgc3Vic2NyaXB0aW9uIHRlcm1p bmF0ZXMgYW5kIGFmdGVyIGEgd2hpbGUgDQp0aGUgc3Vic2NyaWJlciB3YW50cyB0byByZXN1bWUg YSBzdWJzY3JpcHRpb24sJm5ic3A7dGhlIHByb2JsZW0gaXMmbmJzcDtob3cgZG9lcyANCnRoZSBz dWJzY3JpYmVyIGRlYWxzIHdpdGggdGhlIFN1cHByZXNzLUlmLU1hdGNoIGhlYWRlciBmaWVsZD8g RG9lcyBpdCBpbmNsdWRlIA0Kb25lIG9mIHRoZSBTSVAtRXRhZyB2YWx1ZSBvciBib3RoIG9mIHRo ZW0/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kz48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TPkJlc3QgUmVnYXJkcyw8L0ZPTlQ+PC9ESVY+DQo8 RElWPg0KPFA+PC9QPg0KPFA+PC9QPjxGT05UIGZhY2U95Y2O5paH57uG6buRIGNvbG9yPWJsYWNr IHNpemU9Mj53YW5neGlhbmdqdW48QlI+PC9GT05UPjxGT05UIGZhY2U95Y2O5paH57uG6buRIA0K Y29sb3I9Z3JheSBzaXplPTI+5Y2O5Li65oqA5pyv5pyJ6ZmQ5YWs5Y+4IDwvRk9OVD48SU1HIGlk PXJpZEltZyBhbHQ9aHVhd2VpX2xvZ28gaHNwYWNlPTAgDQpzcmM9ImNpZDowMTI0MDFjOWUxOGUk YzM5ZWNlMjAkYmExYzU1MGFAY2hpbmEuaHVhd2VpLmNvbSIgYWxpZ249bGVmdD4gDQo8UD48L1A+ PEJSPjxGT05UIGZhY2U95Y2O5paH57uG6buRIGNvbG9yPWdyYXkgc2l6ZT0xPuWcsOWdgO+8mua3 seWcs+W4gum+meWyl+WMuuWdgueUsOWNjuS4uuWfuuWcsCDpgq7nvJbvvJo1MTgxMjk8QlI+PEEg DQpocmVmPSJodHRwOi8vd3d3Lmh1YXdlaS5jb20iPmh0dHA6Ly93d3cuaHVhd2VpLmNvbTwvQT48 QlI+PC9GT05UPjxGT05UIGZhY2U95Y2O5paH57uG6buRIA0KY29sb3I9Z3JheSANCnNpemU9MT4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPEJSPuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4uuWF rOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4reWI l+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgTxCUj7mraLku7vkvZXlhbbku5bkurrku6Xku7vk vZXlvaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3pmZDkuo7lhajpg6jmiJbpg6jliIblnLDms4Tp nLLjgIHlpI3liLbjgIHmiJbmlaPlj5HvvInmnKzpgq7ku7bkuK08QlI+55qE5L+h5oGv44CC5aaC 5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa 55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yBPEJSPjwvRk9OVD48Rk9OVCANCmZhY2U9 QXJpYWwgY29sb3I9Z3JheSBzaXplPTE+VGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBj b250YWluIA0KY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCA8QlI+ aXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiANCm9yIGVudGl0eSB3aG9zZSBhZGRyZXNz IGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUgPEJSPmluZm9ybWF0aW9uIA0KY29udGFp bmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90 YWwgb3IgcGFydGlhbCANCjxCUj5kaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWlu YXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgDQppbnRlbmRlZCA8QlI+cmVjaXBpZW50 KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCAN CnBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSA8QlI+cGhvbmUgb3IgZW1haWwgaW1tZWRpYXRl bHkgYW5kIGRlbGV0ZSANCml0ITxCUj48L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxl PSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4 OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAg PERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSA8L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0IOWu i+S9kzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9YWRhbUBu b3N0cnVtLmNvbSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSI+QWRhbSBSb2FjaDwvQT4g PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlRvOjwvQj4gPEEgdGl0 bGU9c2lwY29yZUBpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPlNJ UENPUkU8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TZW50 OjwvQj4gVGh1cnNkYXksIEFwcmlsIDIzLCAyMDA5IDEyOjEzIEFNPC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlN1YmplY3Q6PC9CPiBbc2lwY29yZV0gRm9ya2luZyBh bmQgDQogIGRyYWZ0LWlldGYtc2lwY29yZS1zdWJub3QtZXRhZ3M8L0RJVj4NCiAgPERJVj48QlI+ PC9ESVY+W2FzIGFuIGluZGl2aWR1YWwgcGFydGljaXBhbnRdPEJSPjxCUj5Zb3UndmUgcHJvYmFi bHkgbm90aWNlZCBhIA0KICBuZXcgdmVyc2lvbiBvZiB0aGUgc3Vibm90LWV0YWdzIGRvY3VtZW50 IGp1c3QgPEJSPmNhbWUgb3V0LiBUaGlzIHZlcnNpb24gDQogIGluY29ycG9yYXRlcyBzb21lIGNo YW5nZXMgdG8gcmVzb2x2ZSBhIDxCUj5sYXN0LW1pbnV0ZSB0ZWNobmljYWwgaXNzdWUgd2l0aCAN CiAgdGhlIHdheSB0aGlzIGRvY3VtZW50IGludGVyYWN0cyB3aXRoIDxCUj5yZXF1ZXN0IGZvcmtp bmcuIChUaGVyZSdzIGFsc28gYW4gDQogIEFCTkYgY2hhbmdlLCBidXQgdGhlcmUncyBhIHNlcGFy YXRlIDxCUj50aHJlYWQgZ29pbmcgb24gdGhhdCB0b3BpYykuPEJSPjxCUj5JbiANCiAgcHJldmlv dXMgdmVyc2lvbnMgb2YgdGhlIGRvY3VtZW50LCB0aGUgbGFuZ3VhZ2UgYWxsb3dlZCBjb21wbGV0 ZSANCiAgPEJSPnN1cHByZXNzaW9uIG9mIE5PVElGWSBtZXNzYWdlcyBleGNlcHQgd2hlbiB0aGVy ZSB3ZXJlICJyZXBvcnRhYmxlIA0KICA8QlI+Y2hhbmdlcyBpbiB0aGUgTk9USUZZIGhlYWRlciIu IFRoaXMgY3JpdGVyaWEgd2FzIHNvbWV3aGF0IGFtYmlndW91cyBpbiANCiAgPEJSPnRoZSBnZW5l cmFsIGNhc2Ugb2YgZXN0YWJsaXNoaW5nIGEgbmV3IHN1YnNjcmlwdGlvbiAodGhlIHRyYW5zaXRp b24gb2YgDQogIDxCUj5zdWJzY3JpcHRpb24gc3RhdGUgdG8gImFjdGl2ZSIgdGVjaG5pY2FsbHkg cXVhbGlmaWVzIGFzIGEgInJlcG9ydGFibGUgDQogIDxCUj5jaGFuZ2UgaW4gdGhlIE5PVElGWSBo ZWFkZXIiLCBidXQgaW1wbGVtZW50b3JzIHdlcmUgbGVmdCB0byBmaWd1cmUgdGhpcyANCiAgPEJS Pm91dCBpbmRlcGVuZGVudGx5KS4gVG8gY29tcGxpY2F0ZSBtYXR0ZXJzLCB0aGVyZSB3ZXJlIGF0 IGxlYXN0IHR3byANCiAgPEJSPnBhc3NhZ2VzIGluIHRoZSBkb2N1bWVudCB0aGF0IHN0cm9uZ2x5 IHN1Z2dlc3RlZCB0aGF0IHRoZXJlIG1heSBiZSANCiAgPEJSPmNpcmN1bXN0YW5jZXMgaW4gd2hp Y2ggdGhlIGZpcnN0IE5PVElGWSBpbiBhIHN1YnNjcmlwdGlvbiB3b3VsZCBiZSANCiAgPEJSPmNv bXBsZXRlbHkgc3VwcHJlc3NlZCwgd2hpY2ggY2F1c2VzIHNvbWUgc2VyaW91cyBpc3N1ZXMgd2l0 aCANCiAgZm9ya2luZy48QlI+PEJSPlRoZSBjb21wbGV0ZSBzdXBwcmVzc2lvbiBvZiBOT1RJRlkg bWVzc2FnZXMgd2FzIGFsc28gZXhwbGljaXQgDQogIGZvciA8QlI+cmVzb3VyY2Ugc3RhdGUgcG9s bGluZywgd2hpY2ggZ2l2ZXMgcmlzZSB0byBzaW1pbGFyIGlzc3Vlcy48QlI+PEJSPlRoZSANCiAg aXNzdWUgd2l0aCBzdXBwcmVzc2luZyB0aGUgZmlyc3QgTk9USUZZIG1lc3NhZ2UgaW4gYSBkaWFs b2cgaXMgdGhhdCA8QlI+YSANCiAgZm9ya2VkIFNVQlNDUklCRSBtZXNzYWdlIGNhbiBsYW5kIG9u IHNldmVyYWwgbm90aWZpZXJzLCBlYWNoIG9mIHdob20gPEJSPm1heSANCiAgd2VsbCBhY2NlcHQg dGhlIHN1YnNjcmlwdGlvbi4gSG93ZXZlciwgZHVlIHRvIFNJUCBmb3JraW5nIDxCUj5wcm9jZXNz aW5nLCBvbmx5IA0KICBvbmUgZmluYWwgcmVzcG9uc2UgdG8gdGhlIFNVQlNDUklCRSB3aWxsIGFy cml2ZSBhdCB0aGUgDQogIDxCUj5zdWJzY3JpYmVyLjxCUj48QlI+VW5kZXIgdGhlIDMyNjUgbW9k ZWwsIHRoaXMgaXMgcmVzb2x2ZWQgYnkgdGhlIHVzZSBvZiBhbiANCiAgaW1tZWRpYXRlIE5PVElG WSA8QlI+aW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uIC0tIHRoZSBzdWJzY3JpYmVyIGxlYXJucyBh Ym91dCANCiAgYWxsIHRoZSA8QlI+cmVzdWx0aW5nIHN1YnNjcmlwdGlvbnMgYmVjYXVzZSBpdCBy ZWNlaXZlcyBhIE5PVElGWSBtZXNzYWdlIGZvciANCiAgZWFjaCA8QlI+b25lLiBSZW1vdmluZyB0 aGlzIGFzcGVjdCBvZiBzdWJzY3JpcHRpb24gZXN0YWJsaXNobWVudCBiYXNpY2FsbHkgDQogIDxC Uj5yZS1jcmVhdGVzIGEgdmFyaWFudCBvZiB0aGUgSEVSRlAgcHJvYmxlbSwgZXhjZXB0IG11Y2gg d29yc2U6IGluc3RlYWQgb2YgDQogIDxCUj5mYWlsaW5nIHRvIGxlYXJuIGFib3V0IHZhcmlvdXMg cmVxdWVzdCBmYWlsdXJlcywgdGhlIHN1YnNjcmliZXIgZmFpbHMgdG8gDQogIDxCUj5sZWFybiBh Ym91dCB2YXJpb3VzIHN1Y2Nlc3NmdWwgZGlhbG9nIGVzdGFibGlzaG1lbnRzLjxCUj48QlI+VGhl IG1vc3QgDQogIHJlY2VudCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBhZGRyZXNzZXMgdGhpcyBi eTo8QlI+PEJSPiZuYnNwOyZuYnNwOyAxLiANCiAgQ2xlYW5pbmcgdXAgdGhlIHBhc3NhZ2VzIHRo YXQgaW1wbGllZCBzdXBwcmVzc2lvbiBvZiB0aGUgDQogIGluaXRpYWw8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5PVElGWSBtZXNzYWdlIGluIGEgDQogIGRpYWxvZzxCUj48QlI+ Jm5ic3A7Jm5ic3A7IDIuIE1ha2luZyBleHBsaWNpdCB0aGUgcHJldmlvdXNseSBpbXBsaWNpdCBi ZWhhdmlvciANCiAgb2Ygbm90PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdXBw cmVzc2luZyBpbml0aWFsIE5PVElGWSBtZXNzYWdlIGluIA0KICBhIGRpYWxvZzxCUj48QlI+Jm5i c3A7Jm5ic3A7IDMuIENoYW5naW5nIHBvbGwgYmVoYXZpb3IgdG8gcmVxdWlyZSBlbXB0eSBOT1RJ RlkgDQogIG1lc3NhZ2VzIGluc3RlYWQgb2Y8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNvbXBsZXRlbHkgc3VwcHJlc3NlZCANCiAgTk9USUZZIG1lc3NhZ2VzPEJSPjxCUj5Pbmx5 IHRoZSB0aGlyZCBjaGFuZ2UgaXMgYW4gYWN0dWFsIGNoYW5nZSBpbiBiZWhhdmlvci4gDQogIFRo ZSBmaXJzdCB0d28gYXJlIDxCUj5zaW1wbHkgbWFraW5nIHByZXZpb3VzbHkgaW1wbGllZCBiZWhh dmlvciANCiAgZXhwbGljaXQuPEJSPjxCUj5JIHJlYWxpemUgdGhhdCB0aGlzIGlzIGEgYml0IG9m IGRlZXAgUkZDIDMyNjUgYXJjYW5hLCBidXQgDQogIHBsZWFzZSB3ZWlnaCA8QlI+aW4gb24gdGhl IGNoYW5nZXMgc28gd2UgY2FuIG1vdmUgdGhlIGRvY3VtZW50IG92ZXIgdGhlIGZpbmlzaCANCiAg bGluZSBzb29uLiANCiAgPEJSPlRoYW5rcyE8QlI+PEJSPi9hPEJSPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPnNpcGNvcmUgDQogIG1haWxpbmcgbGlz dDxCUj48QSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwv QT48QlI+PEEgDQogIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPC9B PjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_smwre5R14G8IJkU+PM58mA)-- --Boundary_(ID_1dO9rlzVpG/ykNpS8ns4pA) Content-id: <012401c9e18e$c39ece20$ba1c550a@china.huawei.com> Content-type: image/jpeg; name=outlook_huawei_logo_cn.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_cn.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_1dO9rlzVpG/ykNpS8ns4pA)-- From adam@nostrum.com Sat May 30 18:43:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D704E3A68CC for ; Sat, 30 May 2009 18:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga7PH52o5y77 for ; Sat, 30 May 2009 18:43:15 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 566BC3A6452 for ; Sat, 30 May 2009 18:43:15 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-101.dsl.rcsntx.swbell.net [70.249.149.101]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n4V1iiSC024390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 20:44:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A21E10C.9070807@nostrum.com> Date: Sat, 30 May 2009 20:44:44 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: wang xiangjun References: <49EF423D.3080700@nostrum.com> <012901c9e18e$c3bdc7d0$ba1c550a@china.huawei.com> In-Reply-To: <012901c9e18e$c3bdc7d0$ba1c550a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 70.249.149.101 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Forking and draft-ietf-sipcore-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 01:43:16 -0000 [as an individual] As with normal RFC 3265 processing, after the initial SUBSCRIBE, the subscriber is responsible for maintaining the multiple subscriptions separately, including the handling of etags. I don't think we cover the exact case you're talking about. I suspect you're pretty much stuck with getting the body for all but one of the forks, and suppressing the subsequent NOTIFY messages. If this is a problem for a specific network, there are a host of solutions that can be engineered through the use of GRUUs. /a wang xiangjun wrote: > Hello Adam, > I have read the draft and your clarification about the forking > situation which is a good job, but I still have a problem about it as > below: > If a subscriber sends a SUBSCRIBE request and the request is forked > to two notifiers by a proxy which establishes two dialogs. The > subscriber will receive two SIP-Etag from the two notifiers > respectively, is it right? Then the subscription terminates and after > a while the subscriber wants to resume a subscription, the problem > is how does the subscriber deals with the Suppress-If-Match header > field? Does it include one of the SIP-Etag value or both of them? > > Best Regards, > wangxiangjun > 华为技术有限公司 huawei_logo > 地址：深圳市龙岗区坂田华为基地 邮编：518129 > http://www.huawei.com > ------------------------------------------------------------------------------------------------------------------------------------- > 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人 > 或群组。禁 > 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散 > 发）本邮件中 > 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed > above. Any use of the > information contained herein in any way (including, but not limited > to, total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, > please notify the sender by > phone or email immediately and delete it! > > ----- Original Message ----- > *From:* Adam Roach > *To:* SIPCORE > *Sent:* Thursday, April 23, 2009 12:13 AM > *Subject:* [sipcore] Forking and draft-ietf-sipcore-subnot-etags > > [as an individual participant] > > You've probably noticed a new version of the subnot-etags document > just > came out. This version incorporates some changes to resolve a > last-minute technical issue with the way this document interacts with > request forking. (There's also an ABNF change, but there's a separate > thread going on that topic). > > In previous versions of the document, the language allowed complete > suppression of NOTIFY messages except when there were "reportable > changes in the NOTIFY header". This criteria was somewhat > ambiguous in > the general case of establishing a new subscription (the > transition of > subscription state to "active" technically qualifies as a "reportable > change in the NOTIFY header", but implementors were left to figure > this > out independently). To complicate matters, there were at least two > passages in the document that strongly suggested that there may be > circumstances in which the first NOTIFY in a subscription would be > completely suppressed, which causes some serious issues with forking. > > The complete suppression of NOTIFY messages was also explicit for > resource state polling, which gives rise to similar issues. > > The issue with suppressing the first NOTIFY message in a dialog is > that > a forked SUBSCRIBE message can land on several notifiers, each of > whom > may well accept the subscription. However, due to SIP forking > processing, only one final response to the SUBSCRIBE will arrive > at the > subscriber. > > Under the 3265 model, this is resolved by the use of an immediate > NOTIFY > in the reverse direction -- the subscriber learns about all the > resulting subscriptions because it receives a NOTIFY message for each > one. Removing this aspect of subscription establishment basically > re-creates a variant of the HERFP problem, except much worse: > instead of > failing to learn about various request failures, the subscriber > fails to > learn about various successful dialog establishments. > > The most recent version of the document addresses this by: > > 1. Cleaning up the passages that implied suppression of the initial > NOTIFY message in a dialog > > 2. Making explicit the previously implicit behavior of not > suppressing initial NOTIFY message in a dialog > > 3. Changing poll behavior to require empty NOTIFY messages > instead of > completely suppressed NOTIFY messages > > Only the third change is an actual change in behavior. The first > two are > simply making previously implied behavior explicit. > > I realize that this is a bit of deep RFC 3265 arcana, but please > weigh > in on the changes so we can move the document over the finish line > soon. > Thanks! > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >