From christer.holmberg@ericsson.com Sun Aug 1 12:47:45 2010 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 790E33A689F for ; Sun, 1 Aug 2010 12:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.764 X-Spam-Level: X-Spam-Status: No, score=-5.764 tagged_above=-999 required=5 tests=[AWL=0.835, 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 nhsRJr9WKVWe for ; Sun, 1 Aug 2010 12:47:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 30AB23A67DA for ; Sun, 1 Aug 2010 12:47:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-11-4c55cf794538 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AB.43.10125.97FC55C4; Sun, 1 Aug 2010 21:48:09 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 1 Aug 2010 21:48:09 +0200 From: Christer Holmberg To: "Elwell, John" , Adam Roach , SIPCORE Date: Sun, 1 Aug 2010 21:48:07 +0200 Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-keep Thread-Index: AcsjXS8VQrlKdK6dS8KXKyc3qtelJAD0Z7VwAp8z5fM= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C24@ESESSCMS0356.eemea.ericsson.se> References: <4C3DC365.1060508@nostrum.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-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-sipcore-keep@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-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: Sun, 01 Aug 2010 19:47:45 -0000 Hi John, First, please also look at the reply I intend to send to Paul's comments. H= e has some issues with the upstream and downstream wording, and I know you = have provided input on that. So, the outcome of that may of course also hav= e impact on new text etc that I suggest for some of your comments. --------------- >This has some minor issues that need fixing before it is ready to go. > >1. In 4.2.2: ". Once negotiated, keep- > alives are sent until the registration is terminated, or until a > subsequent registration refresh request is sent or forwarded. When a > subsequent registration refresh request is sent or forwarded, if a > SIP entity is willing to continue sending keep-alives associated with > the registration, usage of keep-alives MUST be re-negotiated. If > usage is not successfully re-negotiated, the SIP entity MUST cease > sending of keep-alives associated with the registration." >Yet in 4.2.3: > "Once negotiated, keep-alives MUST > be sent for the lifetime of the dialog, until the dialog is > terminated. Once usage of keep-alives associated with a dialog has > been negotiated, it is not possible to re-negotiate the usage > associated with the dialog." > >There seems to be inconsistency between registrations and dialogs. For a r= egistration, keep-alive can be terminated=20 >when the registration is refreshed, whereas for a dialog there is no way t= o terminate keep-alives (without terminating the dialog).=20 >Would it not be better to align the two? The use case for being able to ne= gotiate no keep-alives during a registration that is already using=20 >keep-alives is not clear. It might be simpler to say that, once keep-alive= has been negotiated, it remains in place for the duration of the registrat= ion or dialog. The issue is not related to a need to be able to negotiate no keep-alives d= uinrg a registration that is already using keep-alives. But, as Hadriel poi= nted out at one point, a proxy that is=20 willing to receive keep-alives might not be able to distinguish between an = initial registration and a registration re-fresh. It would need be registra= tion aware. Hadriel did not want to enforce such requirement. Personally I don't see that as a big problem, as registrations aren't refre= shed that often in the first place. But, I would not like to "allign" by ma= ndating renegotiation of keep-alives associated with dialogs with every re-= INVITE/UPDATE, because I'm afraid it would make the mechanism too "heavy". --------------- >2. "When the SIP entity receives the associated response, if the "keep" > parameter in its Via header field of the response contains a > parameter value, it MUST start to send keep-alives towards the same > destination where it would send a subsequent request (e.g. REGISTER > requests and initial requests for dialog) associated with the > registration (if the keep-alive negotiation is for a registration), > or where it would send subsequent mid-dialog requests (if the keep- > alive negotiation is for a dialog)." > >This sentence is rather long. But my main concern is with the dialog-initi= ating case. Whilst "where it would send subsequent mid-dialog requests" is = correct, that is not necessarily where the Via header field entry with 'kee= p' has come from. Or putting it another way, if a non- >record-routing proxy were to include 'keep', sending keep-alives towards t= hat proxy would be pointless. Of course, a non-record-routing proxy should = not include 'keep'. In this case the first mid-dialog request should contai= n 'keep' again, and if the response to that also=20 >contains 'keep' (with a value) then keep-alives can start. >So although the 'keep' in Via in principle works for both registrations an= d dialogues, there are subtle differences. The present wording doesn't seem= to be wrong, but it certainly doesn't convey the real situation very satis= factorily, IMO. It might be useful to have separate=20 >statements for registrations and dialogs. It might also be useful to state= that a non-record-routing proxy MUST NOT insert 'keep' (probably more appr= opriate in 4.4). I guess that proxies that want to SEND keep-alives associated with a dialog= shall also insert themselves in the dialog route set. So, I could add the following text to section 4.3: "A SIP entity MUST NOT indicates willingness to send keep-alives associated= with a dialog, unless it has also inserted itself in the dialog route set = [3261]." ...and the following text to section 4.4: "A SIP entity MUST NOT indicates willingness to receive keep-alives associa= ted with a dialog, unless it has also inserted itself in the dialog route s= et [3261]."=20 (That is more general, and will also cover endpoints, SBCs and B2BUAs that = use Contact instead of Record-Route.) --------------- >3. "Once a SIP entity has negotiated sending of keep-alives associated > with a dialog towards its adjacent upstream SIP entity, it MUST NOT > insert a "keep" parameter in any subsequent SIP requests associated > with the dialog." > >This doesn't seem to be quite correct. A sends 'keep' to B on a dialog-for= ming request. B does not record route. A sends mid-dialog request to C. Sur= ely in this case, A needs to be able to include 'keep'? But this text seems= to forbid it. Correct. I guess the text should say that once the sending of keep-alives a= ssociated with a dialog has been *negotiated*, the SIP entity must not inse= t a "keep" parameter in subsequent requests. --------------- >A note further down seems to cover the points I made in 2 and 3 above, but= I don't think that is satisfactory. In particular, using a note to contrad= ict a MUST NOT is incorrect. > >4. "NOTE: If a SIP entity inserts a "keep" parameter in its Via header > field of an INVITE request, and it receives multiple responses > (provisional or final) associated with the request, as long as at > least one of the responses, per dialog, contains a "keep" parameter > with a parameter value it is seen as an indication that the adjacent > upstream SIP entity is willing to receive keep-alives associated with > the dialog." > >This isn't incorrect, but it is hard to work out what it means. If there i= s a dialog-forming response, and then further responses on that >same dialog, then 'keep' in any one of these should be sufficient. But if = there are multiple dialog-forming responses, then 'keep' on any=20 >one of these will (I assume) apply only to that dialog, and not other dial= ogs formed by other responses. I think there is room for stating=20 >this more clearly. I am not sure how I can make it more clear, but what about the following: "NOTE: As long as at least one response, associated with a dialog, contains= =20 a "keep" parameter with a parameter value it is seen as an indication that = the adjacent upstream SIP entity is willing to receive keep-alives associated with the dialog on which the response is received." --------------- >5. In 4.3: "The SIP entity must support the amount of STUN > which is required to apply the STUN keep-alive mechanism defined in > [RFC5626], and it must support the CRLF keep-alive mechanism defined > in [RFC5626]." > >I assume the use of lower case "must" (two instances) is motivated by the = belief that we are repeating what is in RFC 5626. However, I don't think th= at is correct - we are stating new normative requirements (i.e., to apply t= he mechanisms in RFC 5626 to the cases covered=20 >by this I-D). Therefore I think we should use "MUST" in each case. Similar= ly in 4.4. I guess people like Adam could give guidance on whether to use lower or upp= er case here. --------------- >6. The Security Considerations section merely states: "This specification = does not introduce security considerations in > addition to those specified in [RFC5626]." > >Considering the I-D addresses dialogs, not just registrations, it sounds l= ike this statement might not be sufficient. For example, if a dialog hop cr= osses=20 >a firewall, use of keep-alive is likely to keep the firewall pin-hole open= for an extended period. I leave it to the security experts to determine=20 >whether this is an issue. A registration will also keep the pin-hole open, and frequent sending of SI= P requests will keep the pin-hole open.=20 But, let's see what the security people say. --------------- >7. In section 3: ""keep" parameter: A SIP Via header field parameter that = a SIP entity > can insert in its Via header field of a request to explicitly > indicate willingness to send keep-alives towards it adjacent upstream > SIP entity. If a SIP entity is willing to receive keep-alives from > its adjacent downstream SIP entity, and the Via header field > associated with the adjacent downstream SIP entity contains a "keep" > parameter, the SIP entity willing to receive keep-alives can add an > integer parameter value to that "keep" parameter. The integer > parameter value can be used to indicate a recommended keep-alive > frequency. A zero value indicates that the SIP entity is willing to > receive keep-alives, but that a recommended keep-alive frequency is > not provided." > >This seems top be far too much for a definition. Some of the material shou= ld instead be covered later in the document (and I suspect it already is). Would the following be sufficient: ""keep" parameter: A SIP Via header field parameter that a SIP entity can insert in its Via header field of a request to explicitly indicate willingness to send keep-alives towards its adjacent upstream SIP entity. A SIP entity can also insert the header field in a response to explicitly indicate willingness to receive keep-alives from its adjacent do= wnstream SIP entity." --------------- >Nits: >N1. Change "Eventhough" to "Even though". > >N2. "since usage of keep-alives in most cases are implicitly negotiated" >Change "are" to "is". > >N3. "usage of keep-alives are not implicitly negotiated" >Change "are" to "is". > >N4. "usage keep-alives". Change to "usage of keep-alives". > >N5: "why usage needs to be explicitly negotiated." >The word "why" seems to be wrong. Should it be "where"? I would use "where", but I guess your english is better than mine, so... :) >N6: "towards it adjacent upstream SIP entity" >Change "it" to "its". > >N7: "the amount of STUN which is required" (two instances) >In each case, change to "those aspects of STUN that are required". I'll fix these. Thanks for your comments! Regards. Christer= From christer.holmberg@ericsson.com Sun Aug 1 12:50:38 2010 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 41C103A689F for ; Sun, 1 Aug 2010 12:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.903 X-Spam-Level: X-Spam-Status: No, score=-5.903 tagged_above=-999 required=5 tests=[AWL=0.696, 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 E+meiGSvQM0j for ; Sun, 1 Aug 2010 12:50:37 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8C86D3A67DA for ; Sun, 1 Aug 2010 12:50:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-99-4c55d0266f7a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BA.53.10125.620D55C4; Sun, 1 Aug 2010 21:51:03 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.2.234.1; Sun, 1 Aug 2010 21:51:02 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sun, 1 Aug 2010 21:51:02 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Sun, 1 Aug 2010 21:51:01 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments Thread-Index: AQHLMbLeVQvy4yi+DE2Aa6uwggDdag== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments 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, 01 Aug 2010 19:50:38 -0000 Hi Paul, >I finally got around to reading the keep draftfor the first time in >quite awhile. I have a few comments and questions: > >IMO the usage of "upstream" and "downstream" (which is ubiquitous) is >confusing, because its not evident which is the high ground and which is >the low ground. Normally for SIP I would assume that the sender of a >request is on the high ground, with the request flowing *downstream* >toward the recipient, and the response flowing *upstream* toward the >sender of the request. But most of the text in this draft assumes the >opposite. Perhaps this stems from a view that the "device" is on the low >ground and the registrar is on the high ground. But then 4.1 further >complicates this: After a first thought I probably agree with your comment that the request f= lows *downstream*. I guess I could add some clarification text, to make it clear that "adjacen= t downstream" refers to the adjacent SIP node in which a request is sent. > NOTE: Usage of keep-alives is negotiated per direction. If a SIP > entity has indicated willingness to receive keep-alives from its > adjacent downstream SIP entity, sending of keep-alives towards the > same SIP entity needs to be separately negotiated. > >If that negotiation were performed following the procedures in this >draft then the upstream and dowstream roles would be reversed. I guess the note could be re-written without the "downstream" wording: "NOTE: Usage of keep-alives is negotiated per direction. If a SIP entity has indicated willingness to receive keep-alives from an adjacent SIP entity, sending of keep-alives towards the same SIP entity needs to be separately negotiated." ----------------- >Section 4.2.2: > >IIUC, the keepalive is associated with a flow as defined in 5626. Hence >it isn't appropriate to use this negotiation mechanism on a registration >that doesn't specify a flow. I don't see that stated anywhere. > >(If there was no flow, what would the keepalive state be associated *with*= ?) The second paragraph describes the case when outbound is used, and when you= do have flows.=20 The generic procedure is described in the first paragraph of the section, a= nd it does not talk about flows - it talks about registrations. ----------------- >Section 4.2.3: > >Is there a reason *why* you can't renegotiate the dialog to eliminate >the use of keepalives? (session timers are a similar concept, and they >are renegotiated on/off with every reINVITE/UPDATE.) > >(Maybe there is a good reason - I just don't see it.) People thought that we shouldn't make things too complicated and heavy by a= llowing mid-dialog renegotiations - and especially not *mandating* a renego= tiation with every reINVITE/UPDATE. ----------------- >Section 4.3: > >The following: > > When a SIP entity is about to send a keep-alive, if the SIP entity at > the same time is also about to send or forward a SIP request > associated with the same registration or dialog, for which the keep- > alive is to be sent, the SIP entity MAY choose not to send the keep- > alive, as the SIP request will perform the same keep-alive action. > >seems pretty imprecise. Wouldn't it be more precise to state that every >request sent resets the clock for when a keep-alive needs to be sent? I can use such wording instead, if people think it's better. >Also, while this skipping of the explicit keep-alive makes sense to me, >AFAICT it isn't consistent with -outbound-. So, do you suggest that a SIP request should NOT reset the clock? OR, would you like some note saying that, when keep-alives are implicilty n= egotiated as part of outbound, requests do not reset the timer? ----------------- >Section 5: > >The following has me totally confused: > > SIP Outbound uses the Flow-Timer header field to indicate the server- > recommended keep-alive frequency. However, it will only be sent > between a UA and an edge proxy. Using the "keep" parameter, however, > the sending and receiving of keep-alives might be negotiated between > multiple entities on the signalling path. Since the server- > recommended keep-alive frequency might vary between different SIP > entities, those would have to re-write the Flow-Timer header field > value. In addition, if a SIP entity does not indicate willingness to > receive keep-alives from its adjacent downstream SIP entity, and > receives a Flow-Timer header field in a response, it would have to > remove the Flow-Timer header field from the response. This issue > does not exist for the "keep" parameter, as each SIP entity has its > own individual Via header field. > > (There are too many hypotheticals in it.) > >After reading this, I don't know: > >- can I use keep in conjunction with an outbound registration? I think the draft currently does not explicitly say anything about that, bu= t I think it would be good to add text saying that it is possible. >- if so, does this alter the procedures of outbound - requiring some manip= ulation of the Flow-Timer value? No. The usage of Flow-Timer with outbound is optional, so saying that it MU= ST NOT be used if the draft mechanism is not used does not break anything, = in my opinion. Thanks for your comments! Regards, Christer= From christer.holmberg@ericsson.com Sun Aug 1 12:52:06 2010 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 D55CA3A689F for ; Sun, 1 Aug 2010 12:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=0.596, 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 S3K5nDLLcvg2 for ; Sun, 1 Aug 2010 12:52:06 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C2B4C3A6782 for ; Sun, 1 Aug 2010 12:52:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-e5-4c55d080ec9d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C3.63.10125.080D55C4; Sun, 1 Aug 2010 21:52:32 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.2.234.1; Sun, 1 Aug 2010 21:52:31 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sun, 1 Aug 2010 21:52:31 +0200 From: Christer Holmberg To: Peter Musgrave , SIPCORE Date: Sun, 1 Aug 2010 21:52:30 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep - Peter's comments Thread-Index: AQHLMbMTcjpHnHaouUibtCnVyykoJw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments 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, 01 Aug 2010 19:52:06 -0000 Hi Peter, >I have read draft-ietf-sipcore-keep in detail for the first time. > >I have one questions and some Nits. > >Question: 7.3 Should the TRYING (not shown) from P1 to Alice have >keep=3D30 in it? What if the 200 OK takes e.g. longer than 30sec and the >NAT pinhole closes? It is true that the flow only shows the 200 OK, but the text in section 4.4= responses in general. I guess we could add some text that points out that the keep value should b= e sent as soon as possible, as it may take a while before the final respons= e is sent. -------------- >Nits >1. s/Eventhough/Even though/ > >1.3 "As specified in [RFC5626], usage keep-alives is not implicitly >negotiated for such flows, why usage needs to be explicitly >negotiated." Re-phrase? > >4.2.1 s/The section/This section/ > >4.4 para 2. This paragraph is one sentence. I read it many times - I gave = up. Thanks for your comments! Regards, Christer= From pkyzivat@cisco.com Mon Aug 2 07:58:30 2010 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 023853A6AF8 for ; Mon, 2 Aug 2010 07:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 3mpU4-QsjIdY for ; Mon, 2 Aug 2010 07:58:28 -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 4322F3A6826 for ; Mon, 2 Aug 2010 07:58:28 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOF5VkxAZnwM/2dsb2JhbACgEHGnT5sPhTkEiH8 X-IronPort-AV: E=Sophos;i="4.55,303,1278288000"; d="scan'208";a="142320115" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 02 Aug 2010 14:58:55 +0000 Received: from [10.86.245.127] ([10.86.245.127]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o72Ewt8O012012; Mon, 2 Aug 2010 14:58:55 GMT Message-ID: <4C56DD2F.9060508@cisco.com> Date: Mon, 02 Aug 2010 10:58:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments 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, 02 Aug 2010 14:58:30 -0000 (Just to be clear, all of these comments of mine are as an individual) Christer Holmberg wrote: > Hi Paul, > >> I finally got around to reading the keep draftfor the first time in >> quite awhile. I have a few comments and questions: >> >> IMO the usage of "upstream" and "downstream" (which is ubiquitous) is >> confusing, because its not evident which is the high ground and which is >> the low ground. Normally for SIP I would assume that the sender of a >> request is on the high ground, with the request flowing *downstream* >> toward the recipient, and the response flowing *upstream* toward the >> sender of the request. But most of the text in this draft assumes the >> opposite. Perhaps this stems from a view that the "device" is on the low >> ground and the registrar is on the high ground. But then 4.1 further >> complicates this: > > After a first thought I probably agree with your comment that the request flows *downstream*. > > I guess I could add some clarification text, to make it clear that "adjacent downstream" refers to the adjacent SIP node in which a request is sent. I see three possible ways to clean this up: 1) exchange "upstream" and "downstream" throughout the document. Also include the explanation about what "downstream" means. 2) Reword the text throughout the document to *eliminate* the use of "upstream" and "downstream". 3) Leave the use of upstream and downstream as is, but add a very explicit specification of what it means in this document. Of those, I find (1) or (2) to be equally acceptable. But (3) seems a poor choice to me - even though it will be internally consistent I think it will confuse people due to conflict with typical usage. >> NOTE: Usage of keep-alives is negotiated per direction. If a SIP >> entity has indicated willingness to receive keep-alives from its >> adjacent downstream SIP entity, sending of keep-alives towards the >> same SIP entity needs to be separately negotiated. >> >> If that negotiation were performed following the procedures in this >> draft then the upstream and dowstream roles would be reversed. > > I guess the note could be re-written without the "downstream" wording: > > "NOTE: Usage of keep-alives is negotiated per direction. If a SIP > entity has indicated willingness to receive keep-alives from an > adjacent SIP entity, sending of keep-alives towards the > same SIP entity needs to be separately negotiated." See above. > ----------------- > >> Section 4.2.2: >> >> IIUC, the keepalive is associated with a flow as defined in 5626. Hence >> it isn't appropriate to use this negotiation mechanism on a registration >> that doesn't specify a flow. I don't see that stated anywhere. >> >> (If there was no flow, what would the keepalive state be associated *with*?) > > The second paragraph describes the case when outbound is used, and when you do have flows. > > The generic procedure is described in the first paragraph of the section, and it does not talk about flows - it talks about registrations. I don't see how that works (in the non-outbound case): The purpose of these keepalives is to keep a nat binding open. But that is only useful if the neighboring node then uses that path to send outbound requests. What is there in the keep draft that even *talks* about that? If the keepalives are sent via TCP, then the neighbor will have to use that same TCP connection for outbound requests in order to gain any benefit from the keepalive. If the keepalives are send via UDP, then the neighbor will have to send requests symmetrically from the address/port on which the keepalives are received. If you were to specify that, wouldn't it begin to duplicate outbound? Note that this issue exists for use of keep in dialogs too. The dialog doesn't nail down a connection to be used for the life of the dialog, yet the keepalive mechanism seems to assume it does. For instance, small messages may be sent via UDP and large ones via TCP. I think there is an unstated assumption here that the use of keepalives binds the dialog to a connection. Something needs to be said about how that is supposed to work. > ----------------- > >> Section 4.2.3: >> >> Is there a reason *why* you can't renegotiate the dialog to eliminate >> the use of keepalives? (session timers are a similar concept, and they >> are renegotiated on/off with every reINVITE/UPDATE.) >> >> (Maybe there is a good reason - I just don't see it.) > > People thought that we shouldn't make things too complicated and heavy by allowing mid-dialog renegotiations - and especially not *mandating* a renegotiation with every reINVITE/UPDATE. Well, people manage with session timer. But I don't care very much. > ----------------- > >> Section 4.3: >> >> The following: >> >> When a SIP entity is about to send a keep-alive, if the SIP entity at >> the same time is also about to send or forward a SIP request >> associated with the same registration or dialog, for which the keep- >> alive is to be sent, the SIP entity MAY choose not to send the keep- >> alive, as the SIP request will perform the same keep-alive action. >> >> seems pretty imprecise. Wouldn't it be more precise to state that every >> request sent resets the clock for when a keep-alive needs to be sent? > > I can use such wording instead, if people think it's better. > >> Also, while this skipping of the explicit keep-alive makes sense to me, >> AFAICT it isn't consistent with -outbound-. > > So, do you suggest that a SIP request should NOT reset the clock? > > OR, would you like some note saying that, when keep-alives are implicilty negotiated as part of outbound, requests do not reset the timer? As I said, it makes sense to me to only send keepalives with the path has been idle. But it disturbs me for the keepalive mechanism, which is borrowed from outbound, to diverge from the definition provided by outbound. I think this is perhaps a discussion to have with the authors of outbound. But I'm inclined to want this to be consistent with outbound even if it means sending unnecessary keepalive messages. > ----------------- > >> Section 5: >> >> The following has me totally confused: >> >> SIP Outbound uses the Flow-Timer header field to indicate the server- >> recommended keep-alive frequency. However, it will only be sent >> between a UA and an edge proxy. Using the "keep" parameter, however, >> the sending and receiving of keep-alives might be negotiated between >> multiple entities on the signalling path. Since the server- >> recommended keep-alive frequency might vary between different SIP >> entities, those would have to re-write the Flow-Timer header field >> value. In addition, if a SIP entity does not indicate willingness to >> receive keep-alives from its adjacent downstream SIP entity, and >> receives a Flow-Timer header field in a response, it would have to >> remove the Flow-Timer header field from the response. This issue >> does not exist for the "keep" parameter, as each SIP entity has its >> own individual Via header field. >> >> (There are too many hypotheticals in it.) >> >> After reading this, I don't know: >> >> - can I use keep in conjunction with an outbound registration? > > I think the draft currently does not explicitly say anything about that, but I think it would be good to add text saying that it is possible. > >> - if so, does this alter the procedures of outbound - requiring some manipulation of the Flow-Timer value? > > No. The usage of Flow-Timer with outbound is optional, so saying that it MUST NOT be used if the draft mechanism is not used does not break anything, in my opinion. So, you are saying that this may be used in conjunction with outbound, but then there is a *limitation* on how outbound is implemented? (That the use of Flow-Timer, which is optional in outbound, is forbidden in certain circumstances?) I'm still very confused over exactly what you are trying to say. And I note that there are no normative statements in that text. I can't even begin to suggest an alternative wording for this paragraph. Can you try again to word it so I understand? Or keep trying to explain it to me so I can suggest something that doesn't confuse me? Thanks, Paul From christer.holmberg@ericsson.com Mon Aug 2 10:59:02 2010 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 BC8563A6BDE for ; Mon, 2 Aug 2010 10:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.522, 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 BaLzPoWk2nGX for ; Mon, 2 Aug 2010 10:59:01 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D9F533A6BD3 for ; Mon, 2 Aug 2010 10:59:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-1c-4c57077f931f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8E.0F.10125.F77075C4; Mon, 2 Aug 2010 19:59:27 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.2.234.1; Mon, 2 Aug 2010 19:59:27 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 2 Aug 2010 19:59:26 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Mon, 2 Aug 2010 19:59:26 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments Thread-Index: AcsyUzviv4/PBO+0TeWTR4wt2JNMFwAEqwXY Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C32@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se>, <4C56DD2F.9060508@cisco.com> In-Reply-To: <4C56DD2F.9060508@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments 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, 02 Aug 2010 17:59:02 -0000 Hi, >>>IMO the usage of "upstream" and "downstream" (which is ubiquitous) is >>>confusing, because its not evident which is the high ground and which is >>>the low ground. Normally for SIP I would assume that the sender of a >>>request is on the high ground, with the request flowing *downstream* >>>toward the recipient, and the response flowing *upstream* toward the >>>sender of the request. But most of the text in this draft assumes the >>>opposite. Perhaps this stems from a view that the "device" is on the low >>>ground and the registrar is on the high ground. But then 4.1 further >>>complicates this: >> >>After a first thought I probably agree with your comment that the request= flows *downstream*. >> >>I guess I could add some clarification text, to make it clear that "adjac= ent downstream" refers to the=20 >>adjacent SIP node in which a request is sent. > >I see three possible ways to clean this up: > >1) exchange "upstream" and "downstream" throughout the document. > Also include the explanation about what "downstream" means. > >2) Reword the text throughout the document to *eliminate* the use of > "upstream" and "downstream". I discussed a lot with John Elwell about the wording, to avoid having to fr= equently repeat long sentences etc. So, if we are to eliminate the usage I would like to see a proposal on how = to do it. >3) Leave the use of upstream and downstream as is, but add a very > explicit specification of what it means in this document. If the usage of upstream and downstream is not alligned with the normal mea= ning (as you suggested), I definately think we shall change it. >Of those, I find (1) or (2) to be equally acceptable. But (3) seems a >poor choice to me - even though it will be internally consistent I think >it will confuse people due to conflict with typical usage. I agree. Let me try to add put together some clarification text (your proposal 1), a= nd see whether it makes things more clear. ----------------- >>> NOTE: Usage of keep-alives is negotiated per direction. If a SIP >>> entity has indicated willingness to receive keep-alives from its >>> adjacent downstream SIP entity, sending of keep-alives towards the >>> same SIP entity needs to be separately negotiated. >>> >>> If that negotiation were performed following the procedures in this >>> draft then the upstream and dowstream roles would be reversed. >> >> I guess the note could be re-written without the "downstream" wording: >> >> "NOTE: Usage of keep-alives is negotiated per direction. If a SIP >> entity has indicated willingness to receive keep-alives from an >> adjacent SIP entity, sending of keep-alives towards the >> same SIP entity needs to be separately negotiated." > >See above. Note that the new note text does not use "downstream" or "upstream" wording= , so I don't think it's dependent on the above issue? ----------------- >>> Section 4.2.2: >>> >>> IIUC, the keepalive is associated with a flow as defined in 5626. Hence >>> it isn't appropriate to use this negotiation mechanism on a registratio= n >>> that doesn't specify a flow. I don't see that stated anywhere. >>> >>> (If there was no flow, what would the keepalive state be associated *wi= th*?) >> >>The second paragraph describes the case when outbound is used, and when y= ou do have flows. >> >>The generic procedure is described in the first paragraph of the section,= and it does not talk about flows - it talks about registrations. > >I don't see how that works (in the non-outbound case): > >The purpose of these keepalives is to keep a nat binding open. >But that is only useful if the neighboring node then uses that path to >send outbound requests. What is there in the keep draft that even >*talks* about that? > >If the keepalives are sent via TCP, then the neighbor will have to use >that same TCP connection for outbound requests in order to gain any >benefit from the keepalive. If the keepalives are send via UDP, then the >neighbor will have to send requests symmetrically from the address/port >on which the keepalives are received. That's a good point. I have probably been assuming that the symmetric path usage is part of the = keep-alive mechanism itself, defined in outbound, so there is no need to re= peat that. But, I guess that it is actually part of the outbound mechanism, so we woul= d need to say that it applies also to entities that are willing to send and= /or receive keep-alives. ----------------- >If you were to specify that, wouldn't it begin to duplicate outbound? It would duplicate that specific requirement of Outbound, yes. But, it's still not a duplication of the whole Outbound mechanism. For exam= ple, registrar support is still not required. And, the keep mechanism can be used between any two SIP entities. ----------------- >Note that this issue exists for use of keep in dialogs too. The dialog >doesn't nail down a connection to be used for the life of the dialog, >yet the keepalive mechanism seems to assume it does. For instance, small >messages may be sent via UDP and large ones via TCP. I think there is an >unstated assumption here that the use of keepalives binds the dialog to >a connection. Something needs to be said about how that is supposed to wor= k. Section 13 of Outbound says that one would need to establish both UDP and T= CP flows, but that in most cases it would make more sense to only use TCP. Maybe we could refer to that text? ----------------- >>>Section 4.2.3: >>> >>>Is there a reason *why* you can't renegotiate the dialog to eliminate >>>the use of keepalives? (session timers are a similar concept, and they >>>are renegotiated on/off with every reINVITE/UPDATE.) >>> >>>(Maybe there is a good reason - I just don't see it.) >> >>People thought that we shouldn't make things too complicated and heavy by= allowing mid-dialog renegotiations - and especially not *mandating* a rene= gotiation with every reINVITE/UPDATE. > >Well, people manage with session timer. But I don't care very much. I still think the conecpt of session timer and keep alive is a little diffe= rent. In addition, reINVITE/UPDATE is a central part of the session timer m= echanism itself, while for keep they are only used for the negotiation. ----------------- >>> Section 4.3: >>> >>> The following: >>> >>> When a SIP entity is about to send a keep-alive, if the SIP entity a= t >>> the same time is also about to send or forward a SIP request >>> associated with the same registration or dialog, for which the keep- >>> alive is to be sent, the SIP entity MAY choose not to send the keep- >>> alive, as the SIP request will perform the same keep-alive action. >>> >>> seems pretty imprecise. Wouldn't it be more precise to state that every >>> request sent resets the clock for when a keep-alive needs to be sent? >> >> I can use such wording instead, if people think it's better. >> >>>Also, while this skipping of the explicit keep-alive makes sense to me, >>>AFAICT it isn't consistent with -outbound-. >> >>So, do you suggest that a SIP request should NOT reset the clock? > >>OR, would you like some note saying that, when keep-alives are implicilty= negotiated as part of outbound, requests do not reset the timer? > >As I said, it makes sense to me to only send keepalives with the path >has been idle. But it disturbs me for the keepalive mechanism, which is >borrowed from outbound, to diverge from the definition provided by >outbound. I think this is perhaps a discussion to have with the authors >of outbound. But I'm inclined to want this to be consistent with >outbound even if it means sending unnecessary keepalive messages. My suggestion would be to remove the text, and simply refer to Outbound. We could then have the discussion with the Outbound authors, but it would n= ot delay the keep draft. ----------------- >>> Section 5: >>> >>> The following has me totally confused: >>> >>> SIP Outbound uses the Flow-Timer header field to indicate the server- >>> recommended keep-alive frequency. However, it will only be sent >>> between a UA and an edge proxy. Using the "keep" parameter, however= , >>> the sending and receiving of keep-alives might be negotiated between >>> multiple entities on the signalling path. Since the server- >>> recommended keep-alive frequency might vary between different SIP >>> entities, those would have to re-write the Flow-Timer header field >>> value. In addition, if a SIP entity does not indicate willingness t= o >>> receive keep-alives from its adjacent downstream SIP entity, and >>> receives a Flow-Timer header field in a response, it would have to >>> remove the Flow-Timer header field from the response. This issue >>> does not exist for the "keep" parameter, as each SIP entity has its >>> own individual Via header field. >>> >>> (There are too many hypotheticals in it.) >>> >>> After reading this, I don't know: >>> >>> - can I use keep in conjunction with an outbound registration? >> >>I think the draft currently does not explicitly say anything about that, = but I think it would be good to add text saying that it is possible. >> >>> - if so, does this alter the procedures of outbound - requiring some ma= nipulation of the Flow-Timer value? >> >>No. The usage of Flow-Timer with outbound is optional, so saying that it = MUST NOT be used if the draft mechanism is not used does not break anything= , in my opinion. > >So, you are saying that this may be used in conjunction with outbound, >but then there is a *limitation* on how outbound is implemented? (That >the use of Flow-Timer, which is optional in outbound, is forbidden in >certain circumstances?) Another option would be to say that, if the Flow-Timer is used (because of = Outbound) the keep parameter value MUST be identical to the Flow-Timer valu= e. That would put no restrictions on Outbound, because it does not say anythin= g about whether to use Flow-Timer or not. ----------------- >I'm still very confused over exactly what you are trying to say. And I >note that there are no normative statements in that text. I can't even >begin to suggest an alternative wording for this paragraph. Can you try >again to word it so I understand? Or keep trying to explain it to me so >I can suggest something that doesn't confuse me? The possibility to use keep in conjunction with registration initiated Outb= ound flows does need normative text - no matter how we re-write the note - = so I will try to come up with something :) The purpose of the note it to simply describe why the Flow-Timer header is = not used with the keep mechanism.=20 Regards, Christer= From gonzalo.camarillo@ericsson.com Tue Aug 3 02:16:32 2010 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 DADAD3A698E for ; Tue, 3 Aug 2010 02:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.661 X-Spam-Level: X-Spam-Status: No, score=-103.661 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, 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 enESiA4bKOzb for ; Tue, 3 Aug 2010 02:16:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C4FCB3A67FC for ; Tue, 3 Aug 2010 02:16:31 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-e8-4c57de8beb0d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D4.A2.06895.B8ED75C4; Tue, 3 Aug 2010 11:16:59 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Aug 2010 11:16:59 +0200 Received: from [131.160.126.136] ([131.160.126.136]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Aug 2010 11:16:59 +0200 Message-ID: <4C57DE8A.20700@ericsson.com> Date: Tue, 03 Aug 2010 12:16:58 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: SIPCORE X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2010 09:16:59.0262 (UTC) FILETIME=[A04331E0:01CB32EC] X-Brightmail-Tracker: AAAAAA== Cc: Dale Worley Subject: [sipcore] Alert-Info header field in non-100 1xx 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, 03 Aug 2010 09:16:32 -0000 Hi, RFC 3261 only allows Alert-Info header fields in 180 responses. The SALUD WG would like to be able to insert this header field in any non-100 1xx response. Formally, this change would be an update to RFC 3261. So, we would like to get feedback from the SIPCORE WG on whether or not such a change would be OK. Thanks, Gonzalo From christer.holmberg@ericsson.com Tue Aug 3 02:49:50 2010 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 1A23D3A68DA for ; Tue, 3 Aug 2010 02:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.982 X-Spam-Level: X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=0.618, 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 NZ42r-mK9Z1H for ; Tue, 3 Aug 2010 02:49:49 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C1A933A6827 for ; Tue, 3 Aug 2010 02:49:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-92-4c57e6589fea Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C1.CB.10125.856E75C4; Tue, 3 Aug 2010 11:50:16 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 3 Aug 2010 11:50:15 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 3 Aug 2010 11:50:14 +0200 From: Christer Holmberg To: Gonzalo Camarillo , SIPCORE Date: Tue, 3 Aug 2010 11:50:13 +0200 Thread-Topic: [sipcore] Alert-Info header field in non-100 1xx responses Thread-Index: Acsy7KWEzfyGo7TsQlGTXnSwZ8T17gABHUjg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850CA4C3@ESESSCMS0356.eemea.ericsson.se> References: <4C57DE8A.20700@ericsson.com> In-Reply-To: <4C57DE8A.20700@ericsson.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-Brightmail-Tracker: AAAAAA== Cc: Dale Worley Subject: Re: [sipcore] Alert-Info header field in non-100 1xx 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, 03 Aug 2010 09:49:50 -0000 Hi, I think we shall allow it. (Terminals that don't support it should simply discard it.) Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 3. elokuuta 2010 12:17 > To: SIPCORE > Cc: Dale Worley > Subject: [sipcore] Alert-Info header field in non-100 1xx responses >=20 > Hi, >=20 > RFC 3261 only allows Alert-Info header fields in 180=20 > responses. The SALUD WG would like to be able to insert this=20 > header field in any non-100 1xx response. Formally, this=20 > change would be an update to RFC 3261. So, we would like to=20 > get feedback from the SIPCORE WG on whether or not such a=20 > change would be OK. >=20 > Thanks, >=20 > Gonzalo > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Tue Aug 3 03:32:09 2010 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 386793A68FB for ; Tue, 3 Aug 2010 03:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.038 X-Spam-Level: X-Spam-Status: No, score=-4.038 tagged_above=-999 required=5 tests=[AWL=-1.439, 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 TO7-DkGfjhT8 for ; Tue, 3 Aug 2010 03:32:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 72A183A682E for ; Tue, 3 Aug 2010 03:32:07 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-dc-4c57f043de0d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 61.0E.06895.340F75C4; Tue, 3 Aug 2010 12:32:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 3 Aug 2010 12:32:34 +0200 From: Christer Holmberg To: "Elwell, John" , SIPCORE Date: Tue, 3 Aug 2010 12:32:33 +0200 Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-keep Thread-Index: AcsjXS8VQrlKdK6dS8KXKyc3qtelJAD0Z7VwAp8z5fMAUgS60A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850CA503@ESESSCMS0356.eemea.ericsson.se> References: <4C3DC365.1060508@nostrum.com>, <7F2072F1E0DE894DA4B517B93C6A05850B5C24@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850B5C24@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-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: Tue, 03 Aug 2010 10:32:09 -0000 Hi John,=20 Some more on one of your comments. >>>3. "Once a SIP entity has negotiated sending of keep-alives=20 >>> associated with a dialog towards its adjacent upstream SIP entity,=20 >>> it MUST NOT insert a "keep" parameter in any subsequent SIP requests= =20 >>> associated with the dialog." >>> >>This doesn't seem to be quite correct. A sends 'keep' to B=20 >>on a dialog-forming request. B does not record route. A sends=20 >>mid-dialog request to C. Surely in this case, A needs to be=20 >>able to include 'keep'? But this text seems to forbid it. >=20 >Correct. I guess the text should say that once the sending of=20 >keep-alives associated with a dialog has been *negotiated*,=20 >the SIP entity must not inset a "keep" parameter in=20 >subsequent requests. When taking a second look at the text, I actually think it is correct. It already says that when the sending of keep-alive has been negotiated. It= does not say once the "keep" parameter has been included. Regards, Christer From christer.holmberg@ericsson.com Tue Aug 3 04:47:21 2010 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 CDB5B3A69FD for ; Tue, 3 Aug 2010 04:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.918 X-Spam-Level: X-Spam-Status: No, score=-3.918 tagged_above=-999 required=5 tests=[AWL=-1.319, 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 k2G-g1pNYtv0 for ; Tue, 3 Aug 2010 04:47:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3D92D3A69F5 for ; Tue, 3 Aug 2010 04:47:19 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-e0-4c5801e302d7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5F.C7.06895.3E1085C4; Tue, 3 Aug 2010 13:47:47 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 3 Aug 2010 13:47:47 +0200 From: Christer Holmberg To: Peter Musgrave , SIPCORE Date: Tue, 3 Aug 2010 13:47:46 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep - Peter's comments Thread-Index: AQHLMbMTcjpHnHaouUibtCnVyykoJ5LPkBng Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments 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, 03 Aug 2010 11:47:21 -0000 Hi Peter,=20 Some proposed new/modified text based on your comments. >>I have read draft-ietf-sipcore-keep in detail for the first time. >> >>I have one questions and some Nits. >> >>Question: 7.3 Should the TRYING (not shown) from P1 to Alice have=20 >>keep=3D30 in it? What if the 200 OK takes e.g. longer than 30sec and the= =20 >>NAT pinhole closes? >=20 >It is true that the flow only shows the 200 OK, but the text=20 >in section 4.4 responses in general. >=20 >I guess we could add some text that points out that the keep=20 >value should be sent as soon as possible, as it may take a=20 >while before the final response is sent. What about the following new text in section 4.4. "In the case of an INVITE request, if a SIP entity sends or forwards multi= ple responses (provisional and final) associated with the=20 request, and it indicates willingness to receive keep-alives, it only need= s to insert a "keep" parameter value in one of the responses. The SIP entity SHOULD indicate the willingess to receive keep-alives as soon a= s possible." -------------- =20 >Nits >1. s/Eventhough/Even though/ > >1.3 "As specified in [RFC5626], usage keep-alives is not implicitly=20 >negotiated for such flows, why usage needs to be explicitly=20 >negotiated." Re-phrase? > >4.2.1 s/The section/This section/ > >4.4 para 2. This paragraph is one sentence. I read it many=20 >times - I gave up. I tried to make the paragraph more readable. It still contain a long senten= ce, but please let me know if it's easier to understand now: "When a SIP entity creates or receives a response, and the adjacent downst= ream SIP entity that sent the associated request indicated=20 willingness to send keep-alives, if the SIP entity is willing to receive k= eep-alives associated with the registration (in case of=20 a REGISTER response), or the dialog (in case of a response to an initial r= equest for a dialog, or a response to a mid-dialog=20 target refresh request), from the adjacent downstream SIP entity it MUST a= dd a parameter value to the "keep" parameter, before sending=20 or forwarding the response. The parameter can contain a recommended keep-a= live frequency, or a zero value." Regards, Christer From peter.musgrave@magorcorp.com Tue Aug 3 05:10:51 2010 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 A5DA03A67D1 for ; Tue, 3 Aug 2010 05:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 DwyzcOpjoKDa for ; Tue, 3 Aug 2010 05:10:48 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 907B73A6A15 for ; Tue, 3 Aug 2010 05:10:46 -0700 (PDT) Received: by qyk1 with SMTP id 1so845827qyk.10 for ; Tue, 03 Aug 2010 05:11:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.77 with SMTP id l13mr2583727qac.222.1280837474771; Tue, 03 Aug 2010 05:11:14 -0700 (PDT) Received: by 10.229.34.14 with HTTP; Tue, 3 Aug 2010 05:11:14 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 3 Aug 2010 08:11:14 -0400 Message-ID: From: Peter Musgrave To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments 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, 03 Aug 2010 12:10:51 -0000 Thanks Christer, Inline. On Tue, Aug 3, 2010 at 7:47 AM, Christer Holmberg wrote: > > Hi Peter, > > Some proposed new/modified text based on your comments. > >>>I have read draft-ietf-sipcore-keep in detail for the first time. >>> >>>I have one questions and some Nits. >>> >>>Question: 7.3 Should the TRYING (not shown) from P1 to Alice have >>>keep=3D30 in it? What if the 200 OK takes e.g. longer than 30sec and the >>>NAT pinhole closes? >> >>It is true that the flow only shows the 200 OK, but the text >>in section 4.4 responses in general. >> >>I guess we could add some text that points out that the keep >>value should be sent as soon as possible, as it may take a >>while before the final response is sent. > > What about the following new text in section 4.4. > > =A0 =A0 =A0 =A0"In the case of an INVITE request, if a SIP entity sends o= r forwards multiple responses (provisional and final) associated with the > =A0 =A0 =A0 =A0request, and it indicates willingness to receive keep-aliv= es, it only needs to insert a "keep" parameter value in one of the response= s. The > =A0 =A0 =A0 =A0SIP entity SHOULD indicate the willingess to receive keep-= alives as soon as possible." Sounds good. > > -------------- > >>Nits >>1. s/Eventhough/Even though/ >> >>1.3 "As specified in [RFC5626], usage keep-alives is not implicitly >>negotiated for such flows, why usage needs to be explicitly >>negotiated." Re-phrase? >> >>4.2.1 s/The section/This section/ >> >>4.4 para 2. This paragraph is one sentence. I read it many >>times - I gave up. > > I tried to make the paragraph more readable. It still contain a long sent= ence, but please let me know if it's easier to understand now: - > =A0 =A0 =A0 =A0"When a SIP entity creates or receives a response, and the= adjacent downstream SIP entity that sent the associated request indicated > =A0 =A0 =A0 =A0willingness to send keep-alives, if the SIP entity is will= ing to receive keep-alives associated with the registration (in case of > =A0 =A0 =A0 =A0a REGISTER response), or the dialog (in case of a response= to an initial request for a dialog, or a response to a mid-dialog > =A0 =A0 =A0 =A0target refresh request), from the adjacent downstream SIP = entity it MUST add a parameter value to the "keep" parameter, before sendin= g > =A0 =A0 =A0 =A0or forwarding the response. The parameter can contain a re= commended keep-alive frequency, or a zero value." Better - but I am still getting a stack overflow since I parse "When... A or B ..and...if..or.." How about: If a request from a downstream SIP element indicated support for keep-alives and the upstream element also supports keep-alives then the response from the upstream element MUST contain a parameter value for the "keep". This value can contain a recommended keep-alive value or a zero value. (I have cut out the stuff on what kind of request it is - I am not sure if this distinction was vital?) > > Regards, > > Christer > > From christer.holmberg@ericsson.com Tue Aug 3 05:42:11 2010 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 44B8E3A6A15 for ; Tue, 3 Aug 2010 05:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=-1.517, BAYES_00=-2.599, J_CHICKENPOX_47=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 71mht5rDbniE for ; Tue, 3 Aug 2010 05:42:09 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B66343A63C9 for ; Tue, 3 Aug 2010 05:42:08 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-8d-4c580ebcc9f2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.CE.06895.CBE085C4; Tue, 3 Aug 2010 14:42:36 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 3 Aug 2010 14:42:35 +0200 From: Christer Holmberg To: Paul Kyzivat , SIPCORE Date: Tue, 3 Aug 2010 14:42:34 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path Thread-Index: AcsyUzviv4/PBO+0TeWTR4wt2JNMFwAEqwXYACipJDA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850CA5A9@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se>, <4C56DD2F.9060508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C32@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850B5C32@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path 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, 03 Aug 2010 12:42:11 -0000 Hi Paul, Some proposed new text based on your comment regarding symmetric path.=20 ----------------- =20 >>>> Section 4.2.2: >>>> >>>> IIUC, the keepalive is associated with a flow as defined in 5626.=20 >>>> Hence it isn't appropriate to use this negotiation mechanism on a=20 >>>> registration that doesn't specify a flow. I don't see that stated anyw= here. >>>> >>>> (If there was no flow, what would the keepalive state be associated=20 >>>> *with*?) >>> >>>The second paragraph describes the case when outbound is=20 >>>used, and when you do have flows. >>> >>>The generic procedure is described in the first paragraph=20 >>>of the section, and it does not talk about flows - it talks=20 >>>about registrations. >> >>I don't see how that works (in the non-outbound case): >> >>The purpose of these keepalives is to keep a nat binding open. >>But that is only useful if the neighboring node then uses=20 >>that path to send outbound requests. What is there in the keep draft that= even >>*talks* about that? >> >>If the keepalives are sent via TCP, then the neighbor will=20 >>have to use that same TCP connection for outbound requests in order to ga= in any=20 >>benefit from the keepalive. If the keepalives are send via UDP, then=20 >>the neighbor will have to send requests symmetrically from the=20 >>address/port on which the keepalives are received. >=20 >That's a good point. >=20 >I have probably been assuming that the symmetric path usage=20 >is part of the keep-alive mechanism itself, defined in=20 >outbound, so there is no need to repeat that. >=20 >But, I guess that it is actually part of the outbound=20 >mechanism, so we would need to say that it applies also to=20 >entities that are willing to send and/or receive keep-alives. >=20 >----------------- >=20 >>If you were to specify that, wouldn't it begin to duplicate outbound? >=20 >It would duplicate that specific requirement of Outbound, yes. >=20 >But, it's still not a duplication of the whole Outbound=20 >mechanism. For example, registrar support is still not required. >=20 >And, the keep mechanism can be used between any two SIP entities. For section 4.3, I suggest the following text: "A SIP entity that has negotiated sending of keep-alives associated with a= registration (registration flow if Outbound is used) MUST be prepared to r= eceive=20 SIP messages (requests and responses) associated with the registration fro= m the receiver of the keep-alives on the same IP port:address=20 from where the keep-alives are sent. Likewise, a SIP entity that has negot= iated sending of keep-alives associated with a dialog=20 MUST be prepared to receive SIP messages associated with the dialog from t= he receiver of the keep-alives on the same IP port:address from=20 where the keep-alives are sent." For section 4.4, I suggest the following text: =09 "A SIP entity that has negotiated receiving of keep-alives associated with= a registration (registration flow if Outbound is used) MUST=20 send SIP messages (requests and responses) associated with the registrati= on towards the sender of the keep-alives using the IP address:port=20 from where the keep-alives where received. Likewise, a SIP entity that has= negotiated receiving of keep-alives associated with a dialog MUST=20 send SIP messages associated with the dialog towards the sender of the kee= p-alives using the IP address:port from where the keep-alives where receive= d." Regards, Christer From christer.holmberg@ericsson.com Tue Aug 3 05:52:29 2010 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 4AEF93A69FC for ; Tue, 3 Aug 2010 05:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[AWL=0.891, 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 q7uyrGWZSAGg for ; Tue, 3 Aug 2010 05:52:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D9EC13A6864 for ; Tue, 3 Aug 2010 05:52:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-83-4c581126df4a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F8.D3.10125.621185C4; Tue, 3 Aug 2010 14:52:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 3 Aug 2010 14:52:54 +0200 From: Christer Holmberg To: Peter Musgrave Date: Tue, 3 Aug 2010 14:52:53 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep - Peter's comments Thread-Index: AcszBPmm04lhSAgaQImipW0oqvYEiwABJcnw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850CA5BE@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments 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, 03 Aug 2010 12:52:29 -0000 Hi,=20 >>>4.4 para 2. This paragraph is one sentence. I read it many times - I=20 >>>gave up. >> >>I tried to make the paragraph more readable. It still=20 >>contain a long sentence, but please let me know if it's=20 >>easier to understand now: >> >> =A0 =A0 =A0 =A0"When a SIP entity creates or receives a response, and th= e=20 >> adjacent downstream SIP entity that sent the associated request=20 >> indicated=A0willingness to send keep-alives, if the SIP entity=20 >> is willing to receive keep-alives associated with the registratio= n=20 >> (in case of a REGISTER response), or the dialog (in case of a=20 >> response to an initial request for a dialog, or a response to a m= id-dialog >> =A0 =A0 =A0 target refresh request), from the adjacent downstream SIP e= ntity it MUST=20 >> add a parameter value to the "keep" parameter, before sending >> =A0 =A0 =A0 =A0or forwarding the response. The parameter can contain a r= ecommended keep-alive=20 >> frequency, or a zero value." >> >Better - but I am still getting a stack overflow since I parse "When... A = or B ..and...if..or.." You should take a look at some 3GPP specifications :) >How about: >=20 >If a request from a downstream SIP element indicated support=20 >for keep-alives and the upstream element also supports=20 >keep-alives then the response from the upstream element MUST=20 >contain a parameter value for the "keep". This value can=20 >contain a recommended keep-alive value or a zero value. >=20 >(I have cut out the stuff on what kind of request it is - I=20 >am not sure if this distinction was vital?) I think it is important to indicate the "scope" (registration or dialog) fo= r which the entity Indicates willingess to receive keep-alives. I guess the "in case of..." parts could be removed. Also, the "the response from the upstream element" is a little confusing, b= ecause it seems to refer to some other entity (the "reference point" in the= text is the SIP entity that inserts the value in the keep header). I would= like to use "the SIP entity", as elsewhere in the document. Regards, Christer= From pkyzivat@cisco.com Tue Aug 3 06:49:20 2010 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 1ED073A6937 for ; Tue, 3 Aug 2010 06:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.462 X-Spam-Level: X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 yfEq-eV+wmLS for ; Tue, 3 Aug 2010 06:49:18 -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 05C933A68C6 for ; Tue, 3 Aug 2010 06:49:16 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGa7V0xAZnwM/2dsb2JhbACgCnGnYJtRhTkEiQI X-IronPort-AV: E=Sophos;i="4.55,309,1278288000"; d="scan'208";a="142716698" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2010 13:49:44 +0000 Received: from [10.86.245.127] ([10.86.245.127]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o73Dni7b025138; Tue, 3 Aug 2010 13:49:44 GMT Message-ID: <4C581E77.6060205@cisco.com> Date: Tue, 03 Aug 2010 09:49:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4C57DE8A.20700@ericsson.com> In-Reply-To: <4C57DE8A.20700@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dale Worley , SIPCORE Subject: Re: [sipcore] Alert-Info header field in non-100 1xx 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, 03 Aug 2010 13:49:20 -0000 Gonzalo, Gonzalo Camarillo wrote: > Hi, > > RFC 3261 only allows Alert-Info header fields in 180 responses. The > SALUD WG would like to be able to insert this header field in any > non-100 1xx response. Formally, this change would be an update to RFC > 3261. So, we would like to get feedback from the SIPCORE WG on whether > or not such a change would be OK. [as an individual] I think this is perfectly reasonable. [as co-chair] There is the procedural issue of whether such a change must be done by SIPCORE. The following is from the SIPCORE charter: "Extensions to SIP that add new functionality that would not be required of all implementations will be done outside of this WG." Since the processing of Alert-Info is always optional according to 3261, defining a specific behavior for certain URNs is clearly an extension. And making the header allowable in additional responses also seems to be an extension. So I'm ok with this. Thanks, Paul From peter.musgrave@magorcorp.com Tue Aug 3 06:55:36 2010 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 10BF63A67E1 for ; Tue, 3 Aug 2010 06:55:36 -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.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 aO-Efc-ISYLN for ; Tue, 3 Aug 2010 06:55:35 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 19FF43A6848 for ; Tue, 3 Aug 2010 06:55:35 -0700 (PDT) Received: by qyk8 with SMTP id 8so2920495qyk.10 for ; Tue, 03 Aug 2010 06:56:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.183.132 with SMTP id cg4mr1141962qcb.111.1280843763154; Tue, 03 Aug 2010 06:56:03 -0700 (PDT) Received: by 10.229.34.14 with HTTP; Tue, 3 Aug 2010 06:56:03 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850CA5BE@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA5BE@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 3 Aug 2010 09:56:03 -0400 Message-ID: From: Peter Musgrave To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments 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, 03 Aug 2010 13:55:36 -0000 All ok with me. Thanks, Peter On Tue, Aug 3, 2010 at 8:52 AM, Christer Holmberg wrote: > > Hi, > >>>>4.4 para 2. This paragraph is one sentence. I read it many times - I >>>>gave up. >>> >>>I tried to make the paragraph more readable. It still >>>contain a long sentence, but please let me know if it's >>>easier to understand now: >>> >>> =A0 =A0 =A0 =A0"When a SIP entity creates or receives a response, and t= he >>> =A0 =A0 =A0 =A0adjacent downstream SIP entity that sent the associated = request >>> =A0 =A0 =A0 =A0indicated=A0willingness to send keep-alives, if the SIP = entity >>> =A0 =A0 =A0 =A0is willing to receive keep-alives associated with the re= gistration >>> =A0 =A0 =A0 =A0(in case of a REGISTER response), or the dialog (in case= of a >>> =A0 =A0 =A0 =A0response to an initial request for a dialog, or a respon= se to a mid-dialog >>> =A0=A0 =A0 =A0 target refresh request), from the adjacent downstream SI= P entity it MUST >>> =A0 =A0 =A0 =A0add a parameter value to the "keep" parameter, before se= nding >>> =A0 =A0 =A0 =A0or forwarding the response. The parameter can contain a = recommended keep-alive >>> =A0 =A0 =A0 =A0frequency, or a zero value." >>> >>Better - but I am still getting a stack overflow since I parse "When... A= or B ..and...if..or.." > > You should take a look at some 3GPP specifications :) > >>How about: >> >>If a request from a downstream SIP element indicated support >>for keep-alives and the upstream element also supports >>keep-alives then the response from the upstream element MUST >>contain a parameter value for the "keep". This value can >>contain a recommended keep-alive value or a zero value. >> >>(I have cut out the stuff on what kind of request it is - I >>am not sure if this distinction was vital?) > > I think it is important to indicate the "scope" (registration or dialog) = for which the entity > Indicates willingess to receive keep-alives. > > I guess the "in case of..." parts could be removed. > > Also, the "the response from the upstream element" is a little confusing,= because it seems to refer to some other entity (the "reference point" in t= he text is the SIP entity that inserts the value in the keep header). I wou= ld like to use "the SIP entity", as elsewhere in the document. > > Regards, > > Christer From pkyzivat@cisco.com Tue Aug 3 07:03:39 2010 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 748143A680D for ; Tue, 3 Aug 2010 07:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Sfsj7spLUdgN for ; Tue, 3 Aug 2010 07:03:38 -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 487463A68C6 for ; Tue, 3 Aug 2010 07:03:38 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK++V0xAZnwM/2dsb2JhbACgCnGoAJtVhTkEiQI X-IronPort-AV: E=Sophos;i="4.55,309,1278288000"; d="scan'208";a="142770317" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2010 14:04:06 +0000 Received: from [10.86.245.127] ([10.86.245.127]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o73E46ML003404; Tue, 3 Aug 2010 14:04:06 GMT Message-ID: <4C5821D6.6030907@cisco.com> Date: Tue, 03 Aug 2010 10:04:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Peter Musgrave Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments 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, 03 Aug 2010 14:03:39 -0000 at end... Christer Holmberg wrote: > Hi Peter, > > Some proposed new/modified text based on your comments. > >>> I have read draft-ietf-sipcore-keep in detail for the first time. >>> >>> I have one questions and some Nits. >>> >>> Question: 7.3 Should the TRYING (not shown) from P1 to Alice have >>> keep=30 in it? What if the 200 OK takes e.g. longer than 30sec and the >>> NAT pinhole closes? >> It is true that the flow only shows the 200 OK, but the text >> in section 4.4 responses in general. >> >> I guess we could add some text that points out that the keep >> value should be sent as soon as possible, as it may take a >> while before the final response is sent. > > What about the following new text in section 4.4. > > "In the case of an INVITE request, if a SIP entity sends or forwards multiple responses (provisional and final) associated with the > request, and it indicates willingness to receive keep-alives, it only needs to insert a "keep" parameter value in one of the responses. The > SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible." You really need to consider reliable and unreliable provisionals separately. Either restrict to reliable responses (provisional or final), or else allow in unreliable provisionals preceding a reliable response. (Which might get it going sooner.) As we have seen with o/a, allowing in unreliable provisionals introduces complications, especially when changing values are used. Thanks, Paul From pkyzivat@cisco.com Tue Aug 3 07:18:08 2010 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 0D27C3A67F0 for ; Tue, 3 Aug 2010 07:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.175 X-Spam-Level: X-Spam-Status: No, score=-10.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8] 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 1z8cy2L2NBmt for ; Tue, 3 Aug 2010 07:18:06 -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 E9BF33A6874 for ; Tue, 3 Aug 2010 07:18:05 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADPCV0xAZnwM/2dsb2JhbACgCnGoBptWhTkEiQI X-IronPort-AV: E=Sophos;i="4.55,309,1278288000"; d="scan'208";a="142730695" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2010 14:18:34 +0000 Received: from [10.86.245.127] ([10.86.245.127]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o73EIXAn011417; Tue, 3 Aug 2010 14:18:34 GMT Message-ID: <4C582539.6050606@cisco.com> Date: Tue, 03 Aug 2010 10:18:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se>, <4C56DD2F.9060508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C32@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA5A9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850CA5A9@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path 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, 03 Aug 2010 14:18:08 -0000 Christer Holmberg wrote: > Hi Paul, > > Some proposed new text based on your comment regarding symmetric path. I think the statements you have added below seem reasonable as far as they go, but they only go half way. They say nothing about what the *recipient* of keepalives must do when sending requests. And I have a strong suspicion this is pretty far along toward reinventing -outbound-. I would like to have comments on this from somebody more intimately familiar with -outbound- than I am. Thanks, Paul > ----------------- > >>>>> Section 4.2.2: >>>>> >>>>> IIUC, the keepalive is associated with a flow as defined in 5626. >>>>> Hence it isn't appropriate to use this negotiation mechanism on a >>>>> registration that doesn't specify a flow. I don't see that stated anywhere. >>>>> >>>>> (If there was no flow, what would the keepalive state be associated >>>>> *with*?) >>>> The second paragraph describes the case when outbound is >>>> used, and when you do have flows. >>>> >>>> The generic procedure is described in the first paragraph >>>> of the section, and it does not talk about flows - it talks >>>> about registrations. >>> I don't see how that works (in the non-outbound case): >>> >>> The purpose of these keepalives is to keep a nat binding open. >>> But that is only useful if the neighboring node then uses >>> that path to send outbound requests. What is there in the keep draft that even >>> *talks* about that? >>> >>> If the keepalives are sent via TCP, then the neighbor will >>> have to use that same TCP connection for outbound requests in order to gain any >>> benefit from the keepalive. If the keepalives are send via UDP, then >>> the neighbor will have to send requests symmetrically from the >>> address/port on which the keepalives are received. >> That's a good point. >> >> I have probably been assuming that the symmetric path usage >> is part of the keep-alive mechanism itself, defined in >> outbound, so there is no need to repeat that. >> >> But, I guess that it is actually part of the outbound >> mechanism, so we would need to say that it applies also to >> entities that are willing to send and/or receive keep-alives. >> >> ----------------- >> >>> If you were to specify that, wouldn't it begin to duplicate outbound? >> It would duplicate that specific requirement of Outbound, yes. >> >> But, it's still not a duplication of the whole Outbound >> mechanism. For example, registrar support is still not required. >> >> And, the keep mechanism can be used between any two SIP entities. > > For section 4.3, I suggest the following text: > > "A SIP entity that has negotiated sending of keep-alives associated with a registration (registration flow if Outbound is used) MUST be prepared to receive > SIP messages (requests and responses) associated with the registration from the receiver of the keep-alives on the same IP port:address > from where the keep-alives are sent. Likewise, a SIP entity that has negotiated sending of keep-alives associated with a dialog > MUST be prepared to receive SIP messages associated with the dialog from the receiver of the keep-alives on the same IP port:address from > where the keep-alives are sent." > > For section 4.4, I suggest the following text: > > "A SIP entity that has negotiated receiving of keep-alives associated with a registration (registration flow if Outbound is used) MUST > send SIP messages (requests and responses) associated with the registration towards the sender of the keep-alives using the IP address:port > from where the keep-alives where received. Likewise, a SIP entity that has negotiated receiving of keep-alives associated with a dialog MUST > send SIP messages associated with the dialog towards the sender of the keep-alives using the IP address:port from where the keep-alives where received." > > Regards, > > Christer From christer.holmberg@ericsson.com Tue Aug 3 08:15:29 2010 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 3A3FE3A6898 for ; Tue, 3 Aug 2010 08:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.767 X-Spam-Level: X-Spam-Status: No, score=-3.767 tagged_above=-999 required=5 tests=[AWL=-1.168, 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 NbVXQ+NowFW2 for ; Tue, 3 Aug 2010 08:15:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 840753A687A for ; Tue, 3 Aug 2010 08:15:16 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-5c-4c58329fd12a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 50.21.06895.F92385C4; Tue, 3 Aug 2010 17:15:43 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 3 Aug 2010 17:15:43 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 3 Aug 2010 17:15:42 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep - Peter's comments Thread-Index: AcszFMBNyHzMN+zNSeyD9WTDOiEp+gACSmkH Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C3B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se>, <4C5821D6.6030907@cisco.com> In-Reply-To: <4C5821D6.6030907@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Peter Musgrave Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments 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, 03 Aug 2010 15:15:29 -0000 Hi Paul, >>>> I have read draft-ietf-sipcore-keep in detail for the first time. >>>> >>>> I have one questions and some Nits. >>>> >>>> Question: 7.3 Should the TRYING (not shown) from P1 to Alice have >>>> keep=3D30 in it? What if the 200 OK takes e.g. longer than 30sec and t= he >>>> NAT pinhole closes? >>> It is true that the flow only shows the 200 OK, but the text >>> in section 4.4 responses in general. >>> >>> I guess we could add some text that points out that the keep >>> value should be sent as soon as possible, as it may take a >>> while before the final response is sent. >> >> What about the following new text in section 4.4. >> >> "In the case of an INVITE request, if a SIP entity sends or forwar= ds multiple responses (provisional and final) associated with the >> request, and it indicates willingness to receive keep-alives, it o= nly needs to insert a "keep" parameter value in one of the responses. The >> SIP entity SHOULD indicate the willingess to receive keep-alives a= s soon as possible." > >You really need to consider reliable and unreliable provisionals separatel= y. > >Either restrict to reliable responses (provisional or final), or else >allow in unreliable provisionals preceding a reliable response. (Which >might get it going sooner.) > >As we have seen with o/a, allowing in unreliable provisionals introduces >complications, especially when changing values are used. You are right. I was thinking about that, but must have forgot when I put t= he text together... The text should say that the parameter needs to be inserted in at least one= response that is sent reliably. I see no reason to forbid to, in addition,= also include it in unreliable responses. So, something like: "In the case of an INVITE request, if a SIP entity sends or forwards= multiple responses (provisional and final) associated with the request, and it indicates willingness to receive keep-alives, it onl= y needs to insert a "keep" parameter value in one response that is sent=20 reliably. The SIP entity MAY insert the parameter value also in othe= r responses (relaible and unreliable) associated with the request.=20 The SIP entity SHOULD indicate the willingess to receive keep-alives = as soon as possible." Regards, Christer= From christer.holmberg@ericsson.com Tue Aug 3 08:29:23 2010 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 954C53A68AF for ; Tue, 3 Aug 2010 08:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.394 X-Spam-Level: X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[AWL=-1.395, BAYES_00=-2.599, J_CHICKENPOX_47=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 lyFo1jO0Vebg for ; Tue, 3 Aug 2010 08:29:22 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 214E13A68B6 for ; Tue, 3 Aug 2010 08:29:21 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-3a-4c5835ed2cbd Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D2.42.06895.DE5385C4; Tue, 3 Aug 2010 17:29:50 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 3 Aug 2010 17:29:49 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 3 Aug 2010 17:29:49 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path Thread-Index: AcszFsVdU0goUnZzSwWmCDutGnJBrQACCKqv Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C3C@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se>, <4C56DD2F.9060508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C32@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA5A9@ESESSCMS0356.eemea.ericsson.se>, <4C582539.6050606@cisco.com> In-Reply-To: <4C582539.6050606@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path 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, 03 Aug 2010 15:29:23 -0000 Hi Paul, >>Some proposed new text based on your comment regarding symmetric path. > >I think the statements you have added below seem reasonable as far as >they go, but they only go half way. They say nothing about what the >*recipient* of keepalives must do when sending requests.=20 That is meant to be covered by the text I suggetsed for section 4.4. It say= s that the receiver of keep-alives must send messages towards the sender of= those keep-alives using the address and port from where the keep-alives ar= rived. >And I have a strong suspicion this is pretty far along toward reinventing = -outbound-. I don't agree. Symmetric routing wasn't invented by Outbound. It is used in= NAT scenarios even if you don't use Outbound, in order to ensure that mess= ages pass NATs.=20 For example, entities providing NAT traversal using anchoring/latching use = symmetric routing. We also already have mechanisms like rport to request symmetric response ro= uting. Regards, Christer > ----------------- > >>>>> Section 4.2.2: >>>>> >>>>> IIUC, the keepalive is associated with a flow as defined in 5626. >>>>> Hence it isn't appropriate to use this negotiation mechanism on a >>>>> registration that doesn't specify a flow. I don't see that stated any= where. >>>>> >>>>> (If there was no flow, what would the keepalive state be associated >>>>> *with*?) >>>> The second paragraph describes the case when outbound is >>>> used, and when you do have flows. >>>> >>>> The generic procedure is described in the first paragraph >>>> of the section, and it does not talk about flows - it talks >>>> about registrations. >>> I don't see how that works (in the non-outbound case): >>> >>> The purpose of these keepalives is to keep a nat binding open. >>> But that is only useful if the neighboring node then uses >>> that path to send outbound requests. What is there in the keep draft th= at even >>> *talks* about that? >>> >>> If the keepalives are sent via TCP, then the neighbor will >>> have to use that same TCP connection for outbound requests in order to = gain any >>> benefit from the keepalive. If the keepalives are send via UDP, then >>> the neighbor will have to send requests symmetrically from the >>> address/port on which the keepalives are received. >> That's a good point. >> >> I have probably been assuming that the symmetric path usage >> is part of the keep-alive mechanism itself, defined in >> outbound, so there is no need to repeat that. >> >> But, I guess that it is actually part of the outbound >> mechanism, so we would need to say that it applies also to >> entities that are willing to send and/or receive keep-alives. >> >> ----------------- >> >>> If you were to specify that, wouldn't it begin to duplicate outbound? >> It would duplicate that specific requirement of Outbound, yes. >> >> But, it's still not a duplication of the whole Outbound >> mechanism. For example, registrar support is still not required. >> >> And, the keep mechanism can be used between any two SIP entities. > > For section 4.3, I suggest the following text: > > "A SIP entity that has negotiated sending of keep-alives associated= with a registration (registration flow if Outbound is used) MUST be prepar= ed to receive > SIP messages (requests and responses) associated with the registrat= ion from the receiver of the keep-alives on the same IP port:address > from where the keep-alives are sent. Likewise, a SIP entity that ha= s negotiated sending of keep-alives associated with a dialog > MUST be prepared to receive SIP messages associated with the dialog= from the receiver of the keep-alives on the same IP port:address from > where the keep-alives are sent." > > For section 4.4, I suggest the following text: > > "A SIP entity that has negotiated receiving of keep-alives associat= ed with a registration (registration flow if Outbound is used) MUST > send SIP messages (requests and responses) associated with the reg= istration towards the sender of the keep-alives using the IP address:port > from where the keep-alives where received. Likewise, a SIP entity t= hat has negotiated receiving of keep-alives associated with a dialog MUST > send SIP messages associated with the dialog towards the sender of = the keep-alives using the IP address:port from where the keep-alives where = received." > > Regards, > > Christer= From pkyzivat@cisco.com Tue Aug 3 08:40:28 2010 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 B858A3A6857 for ; Tue, 3 Aug 2010 08:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TfSRNiQvWV94 for ; Tue, 3 Aug 2010 08:40:27 -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 896893A6925 for ; Tue, 3 Aug 2010 08:40:27 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPLUV0xAZnwM/2dsb2JhbACgEXGoKptQhTkEiQ4 X-IronPort-AV: E=Sophos;i="4.55,309,1278288000"; d="scan'208";a="142810004" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2010 15:40:55 +0000 Received: from [10.86.245.127] ([10.86.245.127]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o73FetUi015358; Tue, 3 Aug 2010 15:40:55 GMT Message-ID: <4C583887.8030700@cisco.com> Date: Tue, 03 Aug 2010 11:40:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se>, <4C5821D6.6030907@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850B5C3B@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Peter Musgrave Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments 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, 03 Aug 2010 15:40:29 -0000 at end Christer Holmberg wrote: > Hi Paul, > >>>>> I have read draft-ietf-sipcore-keep in detail for the first time. >>>>> >>>>> I have one questions and some Nits. >>>>> >>>>> Question: 7.3 Should the TRYING (not shown) from P1 to Alice have >>>>> keep=30 in it? What if the 200 OK takes e.g. longer than 30sec and the >>>>> NAT pinhole closes? >>>> It is true that the flow only shows the 200 OK, but the text >>>> in section 4.4 responses in general. >>>> >>>> I guess we could add some text that points out that the keep >>>> value should be sent as soon as possible, as it may take a >>>> while before the final response is sent. >>> What about the following new text in section 4.4. >>> >>> "In the case of an INVITE request, if a SIP entity sends or forwards multiple responses (provisional and final) associated with the >>> request, and it indicates willingness to receive keep-alives, it only needs to insert a "keep" parameter value in one of the responses. The >>> SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible." >> You really need to consider reliable and unreliable provisionals separately. >> >> Either restrict to reliable responses (provisional or final), or else >> allow in unreliable provisionals preceding a reliable response. (Which >> might get it going sooner.) >> >> As we have seen with o/a, allowing in unreliable provisionals introduces >> complications, especially when changing values are used. > > You are right. I was thinking about that, but must have forgot when I put the text together... > > The text should say that the parameter needs to be inserted in at least one response that is sent reliably. I see no reason to forbid to, in addition, also include it in unreliable responses. > > So, something like: > > "In the case of an INVITE request, if a SIP entity sends or forwards multiple responses (provisional and final) associated with the > request, and it indicates willingness to receive keep-alives, it only needs to insert a "keep" parameter value in one response that is sent > reliably. The SIP entity MAY insert the parameter value also in other responses (relaible and unreliable) associated with the request. > The SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible." You have to be very careful with the wording here. (Speaking after bad experience with o/a.) The above doesn't say that the value must be the same if sent more than once, or what should happen if it is not the same. How about: "A SIP entity receiving an initial INVITE request and wishing to indicate a willingness to receive keep-alives, MUST insert a "keep" parameter value in one reliable response to the INVITE. The SIP entity MAY insert an identical "keep" parameter value in other responses to the same INVITE. The SIP entity MUST NOT insert "keep" parameters with differing values in responses to a single INVITE. The SIP entity SHOULD indicate the willingness to receive keep-alives as soon as possible." Thanks, Paul From pkyzivat@cisco.com Tue Aug 3 08:50:19 2010 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 10DB33A685B for ; Tue, 3 Aug 2010 08:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.173 X-Spam-Level: X-Spam-Status: No, score=-10.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8] 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 0KIr-p7VlWkj for ; Tue, 3 Aug 2010 08:50:15 -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 638E73A6A28 for ; Tue, 3 Aug 2010 08:50:14 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIbXV0xAZnwN/2dsb2JhbACgEXGoK5tThTkEiQ4 X-IronPort-AV: E=Sophos;i="4.55,309,1278288000"; d="scan'208";a="142766847" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2010 15:50:37 +0000 Received: from [10.86.245.127] ([10.86.245.127]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o73Foa6q013010; Tue, 3 Aug 2010 15:50:37 GMT Message-ID: <4C583ACC.30902@cisco.com> Date: Tue, 03 Aug 2010 11:50:36 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se>, <4C56DD2F.9060508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C32@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA5A9@ESESSCMS0356.eemea.ericsson.se>, <4C582539.6050606@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850B5C3C@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path 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, 03 Aug 2010 15:50:19 -0000 Christer Holmberg wrote: > Hi Paul, > >>> Some proposed new text based on your comment regarding symmetric path. >> I think the statements you have added below seem reasonable as far as >> they go, but they only go half way. They say nothing about what the >> *recipient* of keepalives must do when sending requests. > > That is meant to be covered by the text I suggetsed for section 4.4. It says that the receiver of keep-alives must send messages towards the sender of those keep-alives using the address and port from where the keep-alives arrived. I don't think that is sufficient for TCP. AFAIK it actually has to be on the same connection. So for instance, if it attempted to open a new connection in the reverse direction to the same address and port, it would quite probably fail. >> And I have a strong suspicion this is pretty far along toward reinventing -outbound-. > > I don't agree. Symmetric routing wasn't invented by Outbound. It is used in NAT scenarios even if you don't use Outbound, in order to ensure that messages pass NATs. > > For example, entities providing NAT traversal using anchoring/latching use symmetric routing. > > We also already have mechanisms like rport to request symmetric response routing. In the case of TCP this comes down to connection reuse, which is covered by outbound on the edge, and by the connection-reuse draft elsewhere. I think you are talking about much the same, unless you are restricting to UDP. Thanks, Paul > Regards, > > Christer > > > >> ----------------- >> >>>>>> Section 4.2.2: >>>>>> >>>>>> IIUC, the keepalive is associated with a flow as defined in 5626. >>>>>> Hence it isn't appropriate to use this negotiation mechanism on a >>>>>> registration that doesn't specify a flow. I don't see that stated anywhere. >>>>>> >>>>>> (If there was no flow, what would the keepalive state be associated >>>>>> *with*?) >>>>> The second paragraph describes the case when outbound is >>>>> used, and when you do have flows. >>>>> >>>>> The generic procedure is described in the first paragraph >>>>> of the section, and it does not talk about flows - it talks >>>>> about registrations. >>>> I don't see how that works (in the non-outbound case): >>>> >>>> The purpose of these keepalives is to keep a nat binding open. >>>> But that is only useful if the neighboring node then uses >>>> that path to send outbound requests. What is there in the keep draft that even >>>> *talks* about that? >>>> >>>> If the keepalives are sent via TCP, then the neighbor will >>>> have to use that same TCP connection for outbound requests in order to gain any >>>> benefit from the keepalive. If the keepalives are send via UDP, then >>>> the neighbor will have to send requests symmetrically from the >>>> address/port on which the keepalives are received. >>> That's a good point. >>> >>> I have probably been assuming that the symmetric path usage >>> is part of the keep-alive mechanism itself, defined in >>> outbound, so there is no need to repeat that. >>> >>> But, I guess that it is actually part of the outbound >>> mechanism, so we would need to say that it applies also to >>> entities that are willing to send and/or receive keep-alives. >>> >>> ----------------- >>> >>>> If you were to specify that, wouldn't it begin to duplicate outbound? >>> It would duplicate that specific requirement of Outbound, yes. >>> >>> But, it's still not a duplication of the whole Outbound >>> mechanism. For example, registrar support is still not required. >>> >>> And, the keep mechanism can be used between any two SIP entities. >> For section 4.3, I suggest the following text: >> >> "A SIP entity that has negotiated sending of keep-alives associated with a registration (registration flow if Outbound is used) MUST be prepared to receive >> SIP messages (requests and responses) associated with the registration from the receiver of the keep-alives on the same IP port:address >> from where the keep-alives are sent. Likewise, a SIP entity that has negotiated sending of keep-alives associated with a dialog >> MUST be prepared to receive SIP messages associated with the dialog from the receiver of the keep-alives on the same IP port:address from >> where the keep-alives are sent." >> >> For section 4.4, I suggest the following text: >> >> "A SIP entity that has negotiated receiving of keep-alives associated with a registration (registration flow if Outbound is used) MUST >> send SIP messages (requests and responses) associated with the registration towards the sender of the keep-alives using the IP address:port >> from where the keep-alives where received. Likewise, a SIP entity that has negotiated receiving of keep-alives associated with a dialog MUST >> send SIP messages associated with the dialog towards the sender of the keep-alives using the IP address:port from where the keep-alives where received." >> >> Regards, >> >> Christer From christer.holmberg@ericsson.com Tue Aug 3 08:59:41 2010 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 C8D3B3A6961 for ; Tue, 3 Aug 2010 08:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.612 X-Spam-Level: X-Spam-Status: No, score=-5.612 tagged_above=-999 required=5 tests=[AWL=0.987, 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 IIoTtyWBACbn for ; Tue, 3 Aug 2010 08:59:40 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 446643A68BD for ; Tue, 3 Aug 2010 08:59:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-f7-4c583d07c35b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 73.98.10125.70D385C4; Tue, 3 Aug 2010 18:00:07 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 3 Aug 2010 18:00:07 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 3 Aug 2010 18:00:06 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 3 Aug 2010 18:00:06 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep - Peter's comments Thread-Index: AcszIkaIX0Yj8CTCRde27Ok8qg7PxgAAP9yU Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C3E@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se>, <4C5821D6.6030907@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3B@ESESSCMS0356.eemea.ericsson.se>, <4C583887.8030700@cisco.com> In-Reply-To: <4C583887.8030700@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Peter Musgrave Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments 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, 03 Aug 2010 15:59:41 -0000 Hi, >>>>>> I have read draft-ietf-sipcore-keep in detail for the first time. >>>>>> >>>>>> I have one questions and some Nits. >>>>>> >>>>>> Question: 7.3 Should the TRYING (not shown) from P1 to Alice have >>>>>> keep=3D30 in it? What if the 200 OK takes e.g. longer than 30sec and= the >>>>>> NAT pinhole closes? >>>>> It is true that the flow only shows the 200 OK, but the text >>>>> in section 4.4 responses in general. >>>>> >>>>> I guess we could add some text that points out that the keep >>>>> value should be sent as soon as possible, as it may take a >>>>> while before the final response is sent. >>>> What about the following new text in section 4.4. >>>> >>>> "In the case of an INVITE request, if a SIP entity sends or forw= ards multiple responses (provisional and final) associated with the >>>> request, and it indicates willingness to receive keep-alives, it= only needs to insert a "keep" parameter value in one of the responses. The >>>> SIP entity SHOULD indicate the willingess to receive keep-alives= as soon as possible." >>> You really need to consider reliable and unreliable provisionals separa= tely. >>> >>> Either restrict to reliable responses (provisional or final), or else >>> allow in unreliable provisionals preceding a reliable response. (Which >>> might get it going sooner.) >>> >>> As we have seen with o/a, allowing in unreliable provisionals introduce= s >>> complications, especially when changing values are used. >> >> You are right. I was thinking about that, but must have forgot when I pu= t the text together... >> >> The text should say that the parameter needs to be inserted in at least = one response that is sent reliably. I see no reason to forbid to, in additi= on, also include it in unreliable responses. >> >> So, something like: >> >> "In the case of an INVITE request, if a SIP entity sends or forwa= rds multiple responses (provisional and final) associated with the >> request, and it indicates willingness to receive keep-alives, it = only needs to insert a "keep" parameter value in one response that is sent >> reliably. The SIP entity MAY insert the parameter value also in o= ther responses (relaible and unreliable) associated with the request. >> The SIP entity SHOULD indicate the willingess to receive keep-aliv= es as soon as possible." > >You have to be very careful with the wording here. >(Speaking after bad experience with o/a.) The above doesn't say that the >value must be the same if sent more than once, or what should happen if >it is not the same. How about: > >"A SIP entity receiving an initial INVITE request and wishing to >indicate a willingness to receive keep-alives, MUST insert a "keep" >parameter value in one reliable response to the INVITE. The SIP entity >MAY insert an identical "keep" parameter value in other responses to the >same INVITE. The SIP entity MUST NOT insert "keep" parameters with >differing values in responses to a single INVITE. The SIP entity SHOULD >indicate the willingness to receive keep-alives as soon as possible." Looks good. I did some editorial changes, to allign with the style in the r= est of the documents. I also changed the text a little, to make sure it doe= sn't look like an INVITE response is the only way of indicating willingess = to receive keep-alives. Also, I removed "initial", because the negotion could take place in a targe= t refresh re-INVITE (assuming no negotiation has taken place before that). How about: "When a SIP entity indicates willingness to receive keep-alives in a respon= se to an INVITE request, it MUST insert a "keep" parameter in one reliable = response to the INVITE. The SIP entity MAY insert an identical "keep" parameter value in other resp= onses to the same INVITE. The SIP entity MUST NOT insert "keep" parameters = with differing values in responses to a single INVITE. The SIP entity SHOULD ind= icate the willingness to receive keep-alives as soon as possible." Regards, Christer= From pkyzivat@cisco.com Tue Aug 3 09:11:36 2010 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 E6AB83A6A96 for ; Tue, 3 Aug 2010 09:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 7QROSYNEbOt8 for ; Tue, 3 Aug 2010 09:11:35 -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 123913A6A90 for ; Tue, 3 Aug 2010 09:11:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACfdV0xAZnwM/2dsb2JhbACgEXGoPJtShTkEiQ4 X-IronPort-AV: E=Sophos;i="4.55,309,1278288000"; d="scan'208";a="142823016" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2010 16:12:03 +0000 Received: from [10.86.245.127] ([10.86.245.127]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o73GC3p2028313; Tue, 3 Aug 2010 16:12:03 GMT Message-ID: <4C583FD3.6060901@cisco.com> Date: Tue, 03 Aug 2010 12:12:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se>, <4C5821D6.6030907@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3B@ESESSCMS0356.eemea.ericsson.se>, <4C583887.8030700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850B5C3E@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Peter Musgrave Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments 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, 03 Aug 2010 16:11:37 -0000 Christer, This text seems ok to me, though I haven't evaluated it in the context of the draft as a whole. We'll see how it all comes together. Thanks, Paul Christer Holmberg wrote: > Hi, > >>>>>>> I have read draft-ietf-sipcore-keep in detail for the first time. >>>>>>> >>>>>>> I have one questions and some Nits. >>>>>>> >>>>>>> Question: 7.3 Should the TRYING (not shown) from P1 to Alice have >>>>>>> keep=30 in it? What if the 200 OK takes e.g. longer than 30sec and the >>>>>>> NAT pinhole closes? >>>>>> It is true that the flow only shows the 200 OK, but the text >>>>>> in section 4.4 responses in general. >>>>>> >>>>>> I guess we could add some text that points out that the keep >>>>>> value should be sent as soon as possible, as it may take a >>>>>> while before the final response is sent. >>>>> What about the following new text in section 4.4. >>>>> >>>>> "In the case of an INVITE request, if a SIP entity sends or forwards multiple responses (provisional and final) associated with the >>>>> request, and it indicates willingness to receive keep-alives, it only needs to insert a "keep" parameter value in one of the responses. The >>>>> SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible." >>>> You really need to consider reliable and unreliable provisionals separately. >>>> >>>> Either restrict to reliable responses (provisional or final), or else >>>> allow in unreliable provisionals preceding a reliable response. (Which >>>> might get it going sooner.) >>>> >>>> As we have seen with o/a, allowing in unreliable provisionals introduces >>>> complications, especially when changing values are used. >>> You are right. I was thinking about that, but must have forgot when I put the text together... >>> >>> The text should say that the parameter needs to be inserted in at least one response that is sent reliably. I see no reason to forbid to, in addition, also include it in unreliable responses. >>> >>> So, something like: >>> >>> "In the case of an INVITE request, if a SIP entity sends or forwards multiple responses (provisional and final) associated with the >>> request, and it indicates willingness to receive keep-alives, it only needs to insert a "keep" parameter value in one response that is sent >>> reliably. The SIP entity MAY insert the parameter value also in other responses (relaible and unreliable) associated with the request. >>> The SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible." >> You have to be very careful with the wording here. >> (Speaking after bad experience with o/a.) The above doesn't say that the >> value must be the same if sent more than once, or what should happen if >> it is not the same. How about: >> >> "A SIP entity receiving an initial INVITE request and wishing to >> indicate a willingness to receive keep-alives, MUST insert a "keep" >> parameter value in one reliable response to the INVITE. The SIP entity >> MAY insert an identical "keep" parameter value in other responses to the >> same INVITE. The SIP entity MUST NOT insert "keep" parameters with >> differing values in responses to a single INVITE. The SIP entity SHOULD >> indicate the willingness to receive keep-alives as soon as possible." > > Looks good. I did some editorial changes, to allign with the style in the rest of the documents. I also changed the text a little, to make sure it doesn't look like an INVITE response is the only way of indicating willingess to receive keep-alives. > > Also, I removed "initial", because the negotion could take place in a target refresh re-INVITE (assuming no negotiation has taken place before that). > > How about: > > "When a SIP entity indicates willingness to receive keep-alives in a response to an INVITE request, it MUST insert a "keep" parameter in one reliable response to the INVITE. > The SIP entity MAY insert an identical "keep" parameter value in other responses to the same INVITE. The SIP entity MUST NOT insert "keep" parameters with > differing values in responses to a single INVITE. The SIP entity SHOULD indicate the willingness to receive keep-alives as soon as possible." > > Regards, > > Christer From christer.holmberg@ericsson.com Tue Aug 3 09:13:11 2010 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 C305C3A6A89 for ; Tue, 3 Aug 2010 09:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.667 X-Spam-Level: X-Spam-Status: No, score=-3.667 tagged_above=-999 required=5 tests=[AWL=-1.068, 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 9r56g8oPviiN for ; Tue, 3 Aug 2010 09:13:10 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 439283A6974 for ; Tue, 3 Aug 2010 09:13:09 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-c8-4c584031db71 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 92.B5.06895.130485C4; Tue, 3 Aug 2010 18:13:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 3 Aug 2010 18:13:37 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 3 Aug 2010 18:13:35 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path Thread-Index: AcszI6BP0XZf5TusRdyMHmKZ3KVk8gAAWdHT Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C3F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se>, <4C56DD2F.9060508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C32@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA5A9@ESESSCMS0356.eemea.ericsson.se>, <4C582539.6050606@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3C@ESESSCMS0356.eemea.ericsson.se>, <4C583ACC.30902@cisco.com> In-Reply-To: <4C583ACC.30902@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path 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, 03 Aug 2010 16:13:12 -0000 Hi, >>>> Some proposed new text based on your comment regarding symmetric path. >>> I think the statements you have added below seem reasonable as far as >>> they go, but they only go half way. They say nothing about what the >>> *recipient* of keepalives must do when sending requests. >> >>That is meant to be covered by the text I suggetsed for section 4.4. It s= ays that the receiver of keep-alives must send messages towards the sender = of those keep-alives using the address and port from where the keep-alives = arrived. > >I don't think that is sufficient for TCP. AFAIK it actually has to be on >the same connection. So for instance, if it attempted to open a new >connection in the reverse direction to the same address and port, it >would quite probably fail. That is true, and at least from my experience that is also how entities pro= viding NAT traversal (with or without outbound) work. >>>And I have a strong suspicion this is pretty far along toward reinventin= g -outbound-. >> >>I don't agree. Symmetric routing wasn't invented by Outbound. It is used = in NAT scenarios even if you don't use Outbound, in order to ensure that me= ssages pass NATs. >> >>For example, entities providing NAT traversal using anchoring/latching us= e symmetric routing. >> >>We also already have mechanisms like rport to request symmetric response = routing. > >In the case of TCP this comes down to connection reuse, which is covered >by outbound on the edge, and by the connection-reuse draft elsewhere. Yes. So, there are two options: 1. We say that, for TCP, a connection re-use must be used. 2. We mandate the support of the connection re-use spec (RFC 5923). I guess the only difference between 1) and 2) is that 2) would require the = usage of the "alias" parameter, defined in 5923, while 1) means that suppor= t of keep-alive implicitly also indicates support of connection re-use. Section 6 talks about connection reuse. But, we will most likely have to mo= dify (or even remove) the section, based on above. >I think you are talking about much the same, unless you are restricting to= UDP. Absolutely not :) Regards, Christer= From christer.holmberg@ericsson.com Tue Aug 3 09:15:40 2010 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 B16F03A6A8C for ; Tue, 3 Aug 2010 09:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[AWL=-1.012, 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 x3IUx1nqP2+p for ; Tue, 3 Aug 2010 09:15:39 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 432BE3A6A91 for ; Tue, 3 Aug 2010 09:15:25 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-c6-4c5840b95da4 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 14.D5.06895.9B0485C4; Tue, 3 Aug 2010 18:15:53 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 3 Aug 2010 18:15:52 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 3 Aug 2010 18:13:51 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep - Peter's comments Thread-Index: AcszJp40oaBqAaYQRaGtI58aqtvhfwAAD7QT Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C40@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se>, <4C5821D6.6030907@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3B@ESESSCMS0356.eemea.ericsson.se>, <4C583887.8030700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3E@ESESSCMS0356.eemea.ericsson.se>, <4C583FD3.6060901@cisco.com> In-Reply-To: <4C583FD3.6060901@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Peter Musgrave Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments 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, 03 Aug 2010 16:15:40 -0000 Hi, >This text seems ok to me, though I haven't evaluated it in the context >of the draft as a whole. We'll see how it all comes together. Sure. I will put together a new version as soon as we seem to have a common= view on the principles. It is then easier to do the editorial stuff once w= e have everything on the table. Regards, Christer Christer Holmberg wrote: > Hi, > >>>>>>> I have read draft-ietf-sipcore-keep in detail for the first time. >>>>>>> >>>>>>> I have one questions and some Nits. >>>>>>> >>>>>>> Question: 7.3 Should the TRYING (not shown) from P1 to Alice have >>>>>>> keep=3D30 in it? What if the 200 OK takes e.g. longer than 30sec an= d the >>>>>>> NAT pinhole closes? >>>>>> It is true that the flow only shows the 200 OK, but the text >>>>>> in section 4.4 responses in general. >>>>>> >>>>>> I guess we could add some text that points out that the keep >>>>>> value should be sent as soon as possible, as it may take a >>>>>> while before the final response is sent. >>>>> What about the following new text in section 4.4. >>>>> >>>>> "In the case of an INVITE request, if a SIP entity sends or for= wards multiple responses (provisional and final) associated with the >>>>> request, and it indicates willingness to receive keep-alives, i= t only needs to insert a "keep" parameter value in one of the responses. Th= e >>>>> SIP entity SHOULD indicate the willingess to receive keep-alive= s as soon as possible." >>>> You really need to consider reliable and unreliable provisionals separ= ately. >>>> >>>> Either restrict to reliable responses (provisional or final), or else >>>> allow in unreliable provisionals preceding a reliable response. (Which >>>> might get it going sooner.) >>>> >>>> As we have seen with o/a, allowing in unreliable provisionals introduc= es >>>> complications, especially when changing values are used. >>> You are right. I was thinking about that, but must have forgot when I p= ut the text together... >>> >>> The text should say that the parameter needs to be inserted in at least= one response that is sent reliably. I see no reason to forbid to, in addit= ion, also include it in unreliable responses. >>> >>> So, something like: >>> >>> "In the case of an INVITE request, if a SIP entity sends or forw= ards multiple responses (provisional and final) associated with the >>> request, and it indicates willingness to receive keep-alives, it= only needs to insert a "keep" parameter value in one response that is sent >>> reliably. The SIP entity MAY insert the parameter value also in = other responses (relaible and unreliable) associated with the request. >>> The SIP entity SHOULD indicate the willingess to receive keep-ali= ves as soon as possible." >> You have to be very careful with the wording here. >> (Speaking after bad experience with o/a.) The above doesn't say that the >> value must be the same if sent more than once, or what should happen if >> it is not the same. How about: >> >> "A SIP entity receiving an initial INVITE request and wishing to >> indicate a willingness to receive keep-alives, MUST insert a "keep" >> parameter value in one reliable response to the INVITE. The SIP entity >> MAY insert an identical "keep" parameter value in other responses to the >> same INVITE. The SIP entity MUST NOT insert "keep" parameters with >> differing values in responses to a single INVITE. The SIP entity SHOULD >> indicate the willingness to receive keep-alives as soon as possible." > > Looks good. I did some editorial changes, to allign with the style in the= rest of the documents. I also changed the text a little, to make sure it d= oesn't look like an INVITE response is the only way of indicating willinges= s to receive keep-alives. > > Also, I removed "initial", because the negotion could take place in a tar= get refresh re-INVITE (assuming no negotiation has taken place before that)= . > > How about: > > "When a SIP entity indicates willingness to receive keep-alives in a resp= onse to an INVITE request, it MUST insert a "keep" parameter in one reliabl= e response to the INVITE. > The SIP entity MAY insert an identical "keep" parameter value in other re= sponses to the same INVITE. The SIP entity MUST NOT insert "keep" parameter= s with > differing values in responses to a single INVITE. The SIP entity SHOULD i= ndicate the willingness to receive keep-alives as soon as possible." > > Regards, > > Christer= From pkyzivat@cisco.com Tue Aug 3 09:28:10 2010 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 3D1F43A6A82 for ; Tue, 3 Aug 2010 09:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.472 X-Spam-Level: X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 EkX-p91o3LxC for ; Tue, 3 Aug 2010 09:28:06 -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 A4A3E3A67D0 for ; Tue, 3 Aug 2010 09:28:04 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKvgV0xAZnwN/2dsb2JhbACgEXGoaptPhTkEiQ4 X-IronPort-AV: E=Sophos;i="4.55,309,1278288000"; d="scan'208";a="142828458" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2010 16:28:33 +0000 Received: from [10.86.245.127] ([10.86.245.127]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o73GSWFS025994; Tue, 3 Aug 2010 16:28:32 GMT Message-ID: <4C5843B0.9040301@cisco.com> Date: Tue, 03 Aug 2010 12:28:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se>, <4C56DD2F.9060508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C32@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA5A9@ESESSCMS0356.eemea.ericsson.se>, <4C582539.6050606@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3C@ESESSCMS0356.eemea.ericsson.se>, <4C583ACC.30902@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850B5C3F@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path 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, 03 Aug 2010 16:28:10 -0000 Christer Holmberg wrote: > Hi, > >>>>> Some proposed new text based on your comment regarding symmetric path. >>>> I think the statements you have added below seem reasonable as far as >>>> they go, but they only go half way. They say nothing about what the >>>> *recipient* of keepalives must do when sending requests. >>> That is meant to be covered by the text I suggetsed for section 4.4. It says that the receiver of keep-alives must send messages towards the sender of those keep-alives using the address and port from where the keep-alives arrived. >> I don't think that is sufficient for TCP. AFAIK it actually has to be on >> the same connection. So for instance, if it attempted to open a new >> connection in the reverse direction to the same address and port, it >> would quite probably fail. > > That is true, and at least from my experience that is also how entities providing NAT traversal (with or without outbound) work. > >>>> And I have a strong suspicion this is pretty far along toward reinventing -outbound-. >>> I don't agree. Symmetric routing wasn't invented by Outbound. It is used in NAT scenarios even if you don't use Outbound, in order to ensure that messages pass NATs. >>> >>> For example, entities providing NAT traversal using anchoring/latching use symmetric routing. >>> >>> We also already have mechanisms like rport to request symmetric response routing. >> In the case of TCP this comes down to connection reuse, which is covered >> by outbound on the edge, and by the connection-reuse draft elsewhere. > > Yes. > > So, there are two options: > > 1. We say that, for TCP, a connection re-use must be used. > 2. We mandate the support of the connection re-use spec (RFC 5923). > > I guess the only difference between 1) and 2) is that 2) would require the usage of the "alias" parameter, defined in 5923, while 1) means that support of keep-alive implicitly also indicates support of connection re-use. While rfc5923 allows bidirectional reuse of a TLS connection, it does not for a naked TCP connection. In case of TCP you are forced to open a separate connection in each direction, which presumably won't work in the cases where this draft is interesting. > Section 6 talks about connection reuse. But, we will most likely have to modify (or even remove) the section, based on above. > >> I think you are talking about much the same, unless you are restricting to UDP. > > Absolutely not :) Then perhaps you are talking about something that is impossible. Thanks, Paul From christer.holmberg@ericsson.com Tue Aug 3 09:50:38 2010 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 208F43A67E6 for ; Tue, 3 Aug 2010 09:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.56 X-Spam-Level: X-Spam-Status: No, score=-5.56 tagged_above=-999 required=5 tests=[AWL=1.039, 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 gjW1XShBxb8J for ; Tue, 3 Aug 2010 09:50:37 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D41A43A6878 for ; Tue, 3 Aug 2010 09:50:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-c7-4c584556675b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CB.1B.10125.655485C4; Tue, 3 Aug 2010 18:35:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 3 Aug 2010 18:35:34 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 3 Aug 2010 18:31:03 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path Thread-Index: AcszKOtK2CbDA45HSPS6pvENISl7yQAAFjHb Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C47@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se>, <4C56DD2F.9060508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C32@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA5A9@ESESSCMS0356.eemea.ericsson.se>, <4C582539.6050606@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3C@ESESSCMS0356.eemea.ericsson.se>, <4C583ACC.30902@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3F@ESESSCMS0356.eemea.ericsson.se>, <4C5843B0.9040301@cisco.com> In-Reply-To: <4C5843B0.9040301@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path 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, 03 Aug 2010 16:50:38 -0000 Hi, >>>>>> Some proposed new text based on your comment regarding symmetric pat= h. >>>>> I think the statements you have added below seem reasonable as far as >>>>> they go, but they only go half way. They say nothing about what the >>>>> *recipient* of keepalives must do when sending requests. >>>> That is meant to be covered by the text I suggetsed for section 4.4. I= t says that the receiver of keep-alives must send messages towards the send= er of those keep-alives using the address and port from where the keep-aliv= es arrived. >>> I don't think that is sufficient for TCP. AFAIK it actually has to be o= n >>> the same connection. So for instance, if it attempted to open a new >>> connection in the reverse direction to the same address and port, it >>> would quite probably fail. >> >> That is true, and at least from my experience that is also how entities = providing NAT traversal (with or without outbound) work. >> >>>>> And I have a strong suspicion this is pretty far along toward reinven= ting -outbound-. >>>> I don't agree. Symmetric routing wasn't invented by Outbound. It is us= ed in NAT scenarios even if you don't use Outbound, in order to ensure that= messages pass NATs. >>>> >>>> For example, entities providing NAT traversal using anchoring/latching= use symmetric routing. >>>> >>>> We also already have mechanisms like rport to request symmetric respon= se routing. >>> In the case of TCP this comes down to connection reuse, which is covere= d >>> by outbound on the edge, and by the connection-reuse draft elsewhere. >> >> Yes. >> >> So, there are two options: >> >> 1. We say that, for TCP, a connection re-use must be used. >> 2. We mandate the support of the connection re-use spec (RFC 5923). >> >> I guess the only difference between 1) and 2) is that 2) would require t= he usage of the "alias" parameter, defined in 5923, while 1) means that sup= port of keep-alive implicitly also indicates support of connection re-use. > >While rfc5923 allows bidirectional reuse of a TLS connection, it does >not for a naked TCP connection. In case of TCP you are forced to open a >separate connection in each direction, which presumably won't work in >the cases where this draft is interesting. Ok, you are probably right. >> Section 6 talks about connection reuse. But, we will most likely have to= modify (or even remove) the section, based on above. >> >>> I think you are talking about much the same, unless you are restricting= to UDP. >> >> Absolutely not :) > >Then perhaps you are talking about something that is impossible. We simply say that one must re-use the connection, similar to Outbound (and= other mechanisms). Regards, Christer= From christer.holmberg@ericsson.com Tue Aug 3 12:02:42 2010 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 6C9B93A6AB7 for ; Tue, 3 Aug 2010 12:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=-1.311, BAYES_00=-2.599, J_CHICKENPOX_47=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 pNqtRssGDsl8 for ; Tue, 3 Aug 2010 12:02:41 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 09DFE3A6AD8 for ; Tue, 3 Aug 2010 12:02:38 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-0c-4c5867ea2d8b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E3.2F.06895.AE7685C4; Tue, 3 Aug 2010 21:03:07 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 3 Aug 2010 21:03:06 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 3 Aug 2010 21:03:06 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path Thread-Index: AcszKOtK2CbDA45HSPS6pvENISl7yQAAFjHbAASBaOo= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C48@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850B5C22@ESESSCMS0356.eemea.ericsson.se>, <4C56DD2F.9060508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C32@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA5A9@ESESSCMS0356.eemea.ericsson.se>, <4C582539.6050606@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3C@ESESSCMS0356.eemea.ericsson.se>, <4C583ACC.30902@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3F@ESESSCMS0356.eemea.ericsson.se>, <4C5843B0.9040301@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05850B5C47@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850B5C47@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path 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, 03 Aug 2010 19:02:42 -0000 Hi, Based on the discussion regarding symmetric routing, and some editorial cha= nges, below is some new proposed text for section 4.3: "A SIP entity that has negotiated sending of keep-alives associated with a = registration MUST be prepared to receive, from the receiver of the keep-ali= ves, SIP messages (requests and responses) associated=20 with the registration on the same IP port:address from where the keep-alive= s are sent. If the SIP entity sends the keep-alives over a connection-orien= ted transport protocol, it MUST be prepared to receive SIP messages associa= ted with the registration over the same connection. The same rules apply for SIP message= s associated with a dialog, if the SIP entity has negotiated sending of kee= p-alives associated with a dialog." ...and section 4.4: "A SIP entity that has negotiated receiving of keep-alives associated with = a registration MUST send, towards the sender of the keep-alives, SIP messag= es (requests and responses) associated with the registration=20 using the IP address:port from where the keep-alives are received. If the S= IP entity receives the keep-alives over a connection-oriented transport pro= tocol, it MUST send SIP messages associated with the registration over the same connection, rather than creating a new connectio= n. The same rules apply for SIP messages associated with a dialog, if the S= IP entity has negotiated receiving of keep-alives associated with a dialog.= " Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Chri= ster Holmberg [christer.holmberg@ericsson.com] Sent: Tuesday, August 03, 2010 7:31 PM To: Paul Kyzivat Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symm= etric path Hi, >>>>>> Some proposed new text based on your comment regarding symmetric pat= h. >>>>> I think the statements you have added below seem reasonable as far as >>>>> they go, but they only go half way. They say nothing about what the >>>>> *recipient* of keepalives must do when sending requests. >>>> That is meant to be covered by the text I suggetsed for section 4.4. I= t says that the receiver of keep-alives must send messages towards the send= er of those keep-alives using the address and port from where the keep-aliv= es arrived. >>> I don't think that is sufficient for TCP. AFAIK it actually has to be o= n >>> the same connection. So for instance, if it attempted to open a new >>> connection in the reverse direction to the same address and port, it >>> would quite probably fail. >> >> That is true, and at least from my experience that is also how entities = providing NAT traversal (with or without outbound) work. >> >>>>> And I have a strong suspicion this is pretty far along toward reinven= ting -outbound-. >>>> I don't agree. Symmetric routing wasn't invented by Outbound. It is us= ed in NAT scenarios even if you don't use Outbound, in order to ensure that= messages pass NATs. >>>> >>>> For example, entities providing NAT traversal using anchoring/latching= use symmetric routing. >>>> >>>> We also already have mechanisms like rport to request symmetric respon= se routing. >>> In the case of TCP this comes down to connection reuse, which is covere= d >>> by outbound on the edge, and by the connection-reuse draft elsewhere. >> >> Yes. >> >> So, there are two options: >> >> 1. We say that, for TCP, a connection re-use must be used. >> 2. We mandate the support of the connection re-use spec (RFC 5923). >> >> I guess the only difference between 1) and 2) is that 2) would require t= he usage of the "alias" parameter, defined in 5923, while 1) means that sup= port of keep-alive implicitly also indicates support of connection re-use. > >While rfc5923 allows bidirectional reuse of a TLS connection, it does >not for a naked TCP connection. In case of TCP you are forced to open a >separate connection in each direction, which presumably won't work in >the cases where this draft is interesting. Ok, you are probably right. >> Section 6 talks about connection reuse. But, we will most likely have to= modify (or even remove) the section, based on above. >> >>> I think you are talking about much the same, unless you are restricting= to UDP. >> >> Absolutely not :) > >Then perhaps you are talking about something that is impossible. We simply say that one must re-use the connection, similar to Outbound (and= other mechanisms). Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From gonzalo.camarillo@ericsson.com Wed Aug 4 06:00:21 2010 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 0A4433A67EE for ; Wed, 4 Aug 2010 06:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.634 X-Spam-Level: X-Spam-Status: No, score=-105.634 tagged_above=-999 required=5 tests=[AWL=0.965, 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 ijRKiobtLliy for ; Wed, 4 Aug 2010 06:00:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E54D13A67B3 for ; Wed, 4 Aug 2010 06:00:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-af-4c59647f0ed7 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 83.73.10125.084695C4; Wed, 4 Aug 2010 15:00:48 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Aug 2010 15:00:47 +0200 Received: from [131.160.126.136] ([131.160.126.136]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Aug 2010 15:00:47 +0200 Message-ID: <4C59647F.8060700@ericsson.com> Date: Wed, 04 Aug 2010 16:00:47 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <4C57DE8A.20700@ericsson.com> <4C581E77.6060205@cisco.com> In-Reply-To: <4C581E77.6060205@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Aug 2010 13:00:47.0431 (UTC) FILETIME=[0E7CED70:01CB33D5] X-Brightmail-Tracker: AAAAAA== Cc: Dale Worley , SIPCORE Subject: Re: [sipcore] Alert-Info header field in non-100 1xx 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, 04 Aug 2010 13:00:21 -0000 Hi Paul, thanks for your (individual) opinion on the topic. With respect to the process, I am well aware of the issue. That is why, first, I want to know whether or not somebody has problems with this change. Once we agree on a technical solution, we will easily take care of the process-related issue. The main thing here is to make sure that this proposal is reviewed by the relevant people in both SIPCORE and SALUD. Thanks, Gonalo On 03/08/2010 4:49 PM, Paul Kyzivat wrote: > Gonzalo, > > Gonzalo Camarillo wrote: >> Hi, >> >> RFC 3261 only allows Alert-Info header fields in 180 responses. The >> SALUD WG would like to be able to insert this header field in any >> non-100 1xx response. Formally, this change would be an update to RFC >> 3261. So, we would like to get feedback from the SIPCORE WG on whether >> or not such a change would be OK. > > [as an individual] I think this is perfectly reasonable. > > [as co-chair] There is the procedural issue of whether such a change > must be done by SIPCORE. The following is from the SIPCORE charter: > > "Extensions to SIP that add new functionality that > would not be required of all implementations will be done outside of > this WG." > > Since the processing of Alert-Info is always optional according to 3261, > defining a specific behavior for certain URNs is clearly an extension. > And making the header allowable in additional responses also seems to be > an extension. > > So I'm ok with this. > > Thanks, > Paul From adam@nostrum.com Wed Aug 4 15:22:11 2010 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 790DF3A689F for ; Wed, 4 Aug 2010 15:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.659 X-Spam-Level: X-Spam-Status: No, score=-102.659 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, SPF_PASS=-0.001, 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 BkEkr90x6NiX for ; Wed, 4 Aug 2010 15:22: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 1F6EB3A68DF for ; Wed, 4 Aug 2010 15:22:09 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o74MMLXu093036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Aug 2010 17:22:21 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C59E81D.1050403@nostrum.com> Date: Wed, 04 Aug 2010 17:22:21 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" 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] Preliminary minutes posted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 22:22:11 -0000 [as chair] I have posted a preliminary set of minutes for the face-to-face meeting we had in Maastricht. Please review these minutes and submit any proposed corrections to the chairs. Thank you. http://www.ietf.org/proceedings/78/minutes/sipcore.html /a From christer.holmberg@ericsson.com Wed Aug 4 22:59:50 2010 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 2452B3A67FE for ; Wed, 4 Aug 2010 22:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.55 X-Spam-Level: X-Spam-Status: No, score=-5.55 tagged_above=-999 required=5 tests=[AWL=1.048, BAYES_00=-2.599, 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 33oiZ7LDZeqk for ; Wed, 4 Aug 2010 22:59:49 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E8E5F3A67A7 for ; Wed, 4 Aug 2010 22:59:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-16-4c5a537148b3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 94.04.10125.1735A5C4; Thu, 5 Aug 2010 08:00:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 5 Aug 2010 08:00:17 +0200 From: Christer Holmberg To: SIPCORE , Adam Roach Date: Thu, 5 Aug 2010 08:00:16 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep Thread-Index: Acs0Y3nRNZPtNqcITuOXGoVvfDLt7Q== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850CAACF@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05850CAACFESESSCMS0356eemea_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-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: Thu, 05 Aug 2010 05:59:50 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05850CAACFESESSCMS0356eemea_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the WGLC comments/discussions from John E, Paul K and Peter M I ha= ve submitted a new version (-05) of the keep-alive draft. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05850CAACFESESSCMS0356eemea_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Based on the WGLC comments/discussions from John E, P= aul K and Peter M I have submitted a new version (-05) of the keep-alive dr= aft.
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05850CAACFESESSCMS0356eemea_-- From root@core3.amsl.com Wed Aug 4 23:00:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 77AE53A6890; Wed, 4 Aug 2010 23:00: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: <20100805060002.77AE53A6890@core3.amsl.com> Date: Wed, 4 Aug 2010 23:00:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-05.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, 05 Aug 2010 06:00:02 -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-05.txt Pages : 15 Date : 2010-08-04 This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-05.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-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-04225320.I-D@ietf.org> --NextPart-- From john.elwell@siemens-enterprise.com Thu Aug 5 02:47:22 2010 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 D3E213A6A87 for ; Thu, 5 Aug 2010 02:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, 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 ICrKEb9E7qbn for ; Thu, 5 Aug 2010 02:47:22 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id AD3643A6A4D for ; Thu, 5 Aug 2010 02:47:21 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1077126 for sipcore@ietf.org; Thu, 5 Aug 2010 11:31:51 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 420D01EB82AB for ; Thu, 5 Aug 2010 11:31:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 5 Aug 2010 11:31:51 +0200 From: "Elwell, John" To: "sipcore@ietf.org" Date: Thu, 5 Aug 2010 11:31:49 +0200 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-keep-05.txt Thread-Index: Acs0Y4cRmsVFxALFR3udD0czf4+O1AAHV87g Message-ID: References: <20100805060002.77AE53A6890@core3.amsl.com> In-Reply-To: <20100805060002.77AE53A6890@core3.amsl.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 Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-keep-05.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, 05 Aug 2010 09:47:23 -0000 The changes look good and appear to address my previous concerns. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: 05 August 2010 07:00 > To: i-d-announce@ietf.org > Cc: sipcore@ietf.org > Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-05.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Core Working Group of the IETF. >=20 >=20 > Title : Indication of support for keep-alive > Author(s) : C. Holmberg > Filename : draft-ietf-sipcore-keep-05.txt > Pages : 15 > Date : 2010-08-04 >=20 > This specification defines a new Session Initiation Protocol (SIP) > Via header field parameter, "keep", which allows adjacent SIP > entities to explicitly negotiate usage of the Network Address > Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in > cases where SIP Outbound is not supported, cannot be applied, or > where usage of keep-alives is not implicitly negotiated as part of > the SIP Outbound negotiation. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > = From peter.musgrave@magorcorp.com Thu Aug 5 03:55:44 2010 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 E02333A6A7F for ; Thu, 5 Aug 2010 03:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.117 X-Spam-Level: X-Spam-Status: No, score=-102.117 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Rrs2p4VQvbSs for ; Thu, 5 Aug 2010 03:55:44 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id E92273A6A72 for ; Thu, 5 Aug 2010 03:55:43 -0700 (PDT) Received: by qwe5 with SMTP id 5so4190667qwe.31 for ; Thu, 05 Aug 2010 03:56:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.36.209 with SMTP id u17mr4817503qad.225.1281005773831; Thu, 05 Aug 2010 03:56:13 -0700 (PDT) Received: by 10.229.34.14 with HTTP; Thu, 5 Aug 2010 03:56:13 -0700 (PDT) In-Reply-To: References: <20100805060002.77AE53A6890@core3.amsl.com> Date: Thu, 5 Aug 2010 06:56:13 -0400 Message-ID: From: Peter Musgrave To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-keep-05.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, 05 Aug 2010 10:55:45 -0000 The issues I raised have all been addressed, Thanks, Peter Musgrave On Thu, Aug 5, 2010 at 5:31 AM, Elwell, John wrote: > The changes look good and appear to address my previous concerns. > > John > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: 05 August 2010 07:00 >> To: i-d-announce@ietf.org >> Cc: sipcore@ietf.org >> Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-05.txt >> >> 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. >> >> >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Indication of support for keep-a= live >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : C. Holmberg >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-sipcore-keep-05.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 15 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-08-04 >> >> This specification defines a new Session Initiation Protocol (SIP) >> Via header field parameter, "keep", which allows adjacent SIP >> entities to explicitly negotiate usage of the Network Address >> Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in >> cases where SIP Outbound is not supported, cannot be applied, or >> where usage of keep-alives is not implicitly negotiated as part of >> the SIP Outbound negotiation. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-05.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 alexander.mayrhofer@nic.at Fri Aug 6 02:05:13 2010 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 53E293A68CB for ; Fri, 6 Aug 2010 02:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.556 X-Spam-Level: X-Spam-Status: No, score=0.556 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 onbKkyi5+S+p for ; Fri, 6 Aug 2010 02:05:11 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id 75C4C3A6A8F for ; Fri, 6 Aug 2010 02:05:09 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.45 ; Fri, 6 Aug 2010 10:35:15 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.702.0; Fri, 6 Aug 2010 10:35:15 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 6 Aug 2010 10:35:14 +0200 Message-ID: <8BC845943058D844ABFC73D2220D4665094CC410@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XML bug in Section 5.1 of Location Conveyance? Thread-Index: Acs1QkpQYbkVNggTTLaxRO9moJ/4sw== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [sipcore] XML bug in Section 5.1 of Location Conveyance? 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, 06 Aug 2010 09:05:13 -0000 Hi, i read through version 13 of the Location Conveyance draft, and i think i spotted a bug in the example XML in section 5.1: The PIDF-LO body starts as follows: The last line in the snippet above refers to a namespace that has not been declared - i suppose the namespace declaration of PIDF Data Model is missing. I didn't look at other examples from the draft, but it might be worthwile verifying whether all the XML documents in the draft validate. Alex From dworley@avaya.com Sun Aug 8 09:11:18 2010 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 C07283A68DB for ; Sun, 8 Aug 2010 09:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.809 X-Spam-Level: X-Spam-Status: No, score=-100.809 tagged_above=-999 required=5 tests=[AWL=-1.410, BAYES_50=0.001, J_CHICKENPOX_41=0.6, 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 9aE+Im+Iq4Bk for ; Sun, 8 Aug 2010 09:11:15 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D1A5A3A68B3 for ; Sun, 8 Aug 2010 09:11:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,338,1278302400"; d="scan'208";a="231768196" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 08 Aug 2010 12:11:44 -0400 X-IronPort-AV: E=Sophos;i="4.55,338,1278302400"; d="scan'208";a="490828212" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 Aug 2010 12:11:44 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Sun, 8 Aug 2010 12:11:43 -0400 From: "WORLEY, Dale R (Dale)" To: "sipcore@ietf.org" Date: Sun, 8 Aug 2010 12:09:47 -0400 Thread-Topic: Review of draft-ietf-sipcore-keep-05 Thread-Index: AQHLNxQfbKRBGdvoDEWm/nBr9CW46w== Message-ID: 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 Subject: [sipcore] Review of draft-ietf-sipcore-keep-05 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, 08 Aug 2010 16:11:19 -0000 I've not been in on the technical discussion, so I can't comment on the mechanism design. But the exposition in the draft could be improved in a few places. The running title is "STUN-keep", which is surely not what is intended. Section 1.1 Uses "session" twice, but I think "dialog" is more correct. The session (media) contains the RTP, which will probably keep the NAT open; the problem is keeping the NAT open for the signaling (dialog). Section 3 "Edge proxy" It's not clear that "edge proxy" has any normative significance in this I-D, as this mechanism can be used between any two entities. It seems that this definition and the accompanying Note could be removed at no loss. (The definition needs revision, also.) "Keep-alives" It would help if this definition mentioned that both CRLF and STUN keepalives were intended. Also, the phrase "refers to" should be removed. E.g.: Keep-alives: The keep-alive messages defined in SIP Outbound [RFC5626], including both "CRLF" and STUN keep-alive messages. '"keep" parameter' Strictly speaking, this entry is a description not a definition; the phrase '"keep" parameter' identifies the parameter unambiguously. It would be better to remove this entry and add its information to section 4.1, which needs to be a bit more explicit about the mechanism. (See below.) Section 4.1, 2nd paragraph is: SIP entities indicate willingness to send keep-alives towards the adjacent downstream SIP entity using SIP requests. The associated responses are used by SIP entities to indicate willingness to receive keep-alives. SIP entities that indicate willingness to receive keep- alives can provide a recommended keep-alive frequency. This should be made more explicit. (And can be clarified using the singular.) A SIP entity indicates willingness to send keep-alives towards the adjacent downstream SIP entity using SIP requests by applying a "keep" header parameter to the topmost Via (which is the Via that it inserts). The associated response is used by the adjacent downstream SIP entity to indicate willingness to receive keep-alives by applying to that topmost Via a "keep" header parameter with an integer value. The integer value, if not zero, indicates the keep-alive frequency that is recommended by the adjacent downstream SIP entity. That gives the outline of the mechanism in one paragraph. The 3rd paragraph should probably be expanded to make explicit a somewhat subtle point: The procedures to negotiate usage of keep-alives are identical for SIP UAs and proxies. However, it is expected that the sender of keep-alives is the sender of an initial request (REGISTER or INVITE), which in normal usage is a UA, and so a proxy will not initiate negotiation for sending keep-alives. Thus, a UA which is willing to send keep-alives SHOULD always indicate that it is willing to send keep-alives even if it is not aware of any necessity of doing so, allowing the adjacent downstream entity to indicate if it knows that keep-alives are necessary (by responding with a non-zero value). Similarly, an entity which is willing to receive keep-alives SHOULD always respond with a keep value of zero when it is not aware of any necessity for keep-alives, thus leaving the sender to send keep-alives if the sender is aware of any necessity to do so. Urgh. I suspect that these additions should instead be added to 4.3 and 4.4 as appropriate. But the mechanism needs to be used correctly by both entities in order to ensure that keep-alives are sent when either entity knows that they are needed, and the draft doesn't make explicit how to do that. Section 4.3 It's not clear to me what keep-alives the upstream entity must send once keep-alives are negotiated. The first paragraph says that the entity must be able to send both STUN and CRLF keep-alives, but that seems to be not entirely accurate, as the sender seems to have the choice of what type of keep-alive to send, and so can choose to send only one type. I suspect that there are rules elsewhere regarding what sort of keep-alive is to be sent in what circumstances; if so, there should be a reference to them. Otherwise, a note should be added to indicate that the sender has the choice of what sort of keep-alive to add, and thus does not need to implement both. (The recipient is required to implement both, of course.) Section 4.4 In every place where "frequency" is used, it would be more correct to use "period". (A frequency is events-per-second, whereas a period is seconds-per-event.) In some place it must be stated that the period is specified in seconds, which is not done anywhere in the normative part of this draft. Section 5 In the first paragraph, a few places could be phrased more clearly: If a SIP entity receives a SIP response >>whose topmost<< Via header field contains a "keep" parameter with a non-zero value >>(which indicates a recommended keep-alive period)<<, it MUST use the procedures defined >>in [RFC5626], using the value as if it was the value of the Flow-Timer header field<<. According to >>those<< procedures, the SIP entity must send keep-alives at least as often as the indicated recommended keep-alive >>period<<, >>and the SIP entity should<< send its keep-alives so that the interval between >>keep-alives<< is randomly distributed between 80% and 100% of the recommended keep-alive >>period<<. After this paragraph should be a note saying when the receiving SIP entity is allowed to assume the connection is dead. Copying from RFC 5626, we could say: Following [RFC5626], if a recommended keep-alive period has been negotiated, the receiving SIP entity may, after not receiving a keep-alive for that period, consider the flow to be dead. Note that the entity should wait for a time larger than the period in order to have a grace period to account for transport delay. 3rd paragraph It makes sense that if a single entity inserts both a keep=3Dn parameter and a Flow-Timer: n header that they should contain the same value. But that is of no use to (and is not enforceable by) an upstream SIP entity, since from the upstream entity's point of view, the Flow-Timer header may have been inserted by an entity further downstream, not its adjacent downstream entity. That is, an entity expects to see responses with Flow-Timer and keep=3Dn which disagree, and (I think) must use the keep value instead of the Flow-Timer value. Actually, I think the situation is probably more complex than I realize. The Flow-Timer value seems to apply only between the edge proxy and the UA, and it it seems that only the UAC should pay attention to its value. But it's not clear who can add the Flow-Timer header. It appears that it can only appear in REGISTER responses. It can be added by the UAS (obviously), but it appears from RFC 5626 section 5.4 that it can also be added to the response by intermediate proxies. This section needs revision to make clear the interaction between Flow-Timer and keep=3Dn. I suspect the only workable answer is that an entity must examine both values (if it supports both mechanisms), determine whether Flow-Timer applies to this hop, and if so, send keep-alives according to the minimum of the two specified periods. Since the two periods might be specified by different entities, there doesn't seem to be any workable alternative rule. Section 6 All examples use STUN keep-alives. It would probably be beneficial to change one example to use CRLF, or to add a note explaining whether and when CRLF might be used in the example situations. It is possible for two proxies to use this mechanism on a hop between themselves. Would it be useful to add an example of this? Dale From christer.holmberg@ericsson.com Mon Aug 9 00:20:51 2010 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 C41F73A6A75 for ; Mon, 9 Aug 2010 00:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.996 X-Spam-Level: X-Spam-Status: No, score=-3.996 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_50=0.001, J_CHICKENPOX_41=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 G3O7VRI-zmPb for ; Mon, 9 Aug 2010 00:20:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6A32E3A67F6 for ; Mon, 9 Aug 2010 00:20:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-51-4c5fac7261b1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5C.DB.10125.27CAF5C4; Mon, 9 Aug 2010 09:21:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 9 Aug 2010 09:21:21 +0200 From: Christer Holmberg To: "WORLEY, Dale R (Dale)" , "sipcore@ietf.org" Date: Mon, 9 Aug 2010 09:21:20 +0200 Thread-Topic: Review of draft-ietf-sipcore-keep-05 Thread-Index: AQHLNxQfbKRBGdvoDEWm/nBr9CW465LX0d7F Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850CB1D6@ESESSCMS0356.eemea.ericsson.se> References: 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Review of draft-ietf-sipcore-keep-05 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, 09 Aug 2010 07:20:51 -0000 Hi Dale, Thanks for your comments. See inline. >I've not been in on the technical discussion, so I can't comment on >the mechanism design. But the exposition in the draft could be >improved in a few places. Some of your comments ARE related to issues that were discussed during WGLC= , and I will indicate it when it occurs. -------------- >The running title is "STUN-keep", which is surely not what is intended. I can change that to "keep-alive". -------------- >Section 1.1 > >Uses "session" twice, but I think "dialog" is more correct. The >session (media) contains the RTP, which will probably keep the NAT >open; the problem is keeping the NAT open for the signaling (dialog). I can change "session" to "dialog". -------------- >Section 3 > >"Edge proxy" > >It's not clear that "edge proxy" has any normative significance in >this I-D, as this mechanism can be used between any two entities. >It seems that this definition and the accompanying Note could be >removed at no loss. (The definition needs revision, also.) Section 5 talks about the edge proxy, where it describes that the usage of = Flow-Timer is only defined between a UA and an edge proxy, so I think it is= useful to have the definition. I guess I could also add the following sentence to section 1: "In addition, [RFC5626] only allows keep-alives to be negotiated between a= UA and an edge proxy, and not between other SIP entities." -------------- >"Keep-alives" > >It would help if this definition mentioned that both CRLF and STUN >keepalives were intended. Also, the phrase "refers to" should be >removed. E.g.: > > Keep-alives: The keep-alive messages defined in SIP Outbound > [RFC5626], including both "CRLF" and STUN keep-alive messages. People have asked me to remove text, and make it shorter and easier to read= , so I would not like to start adding text unless something is broken or ve= ry unclear. In this case I think that sections 4.3 and 4.4 makes it clear t= hat both CRLF and STUN are included. But, I DO agree that "refers to" can be removed: "Keep-alives: The keep-alive messages defined in SIP Outbound [RFC562= 6]." -------------- >'"keep" parameter' > >Strictly speaking, this entry is a description not a definition; the >phrase '"keep" parameter' identifies the parameter unambiguously. It >would be better to remove this entry and add its information to >section 4.1, which needs to be a bit more explicit about the >mechanism. (See below.) The definition text used to be even longer, but parts were removed. However= , the terminology is used in the documents, so I think it is good to have i= t in the definitions, instead of writing "the Via header field "keep" param= eter" everywhere. -------------- >Section 4.1, 2nd paragraph is: > > SIP entities indicate willingness to send keep-alives towards the > adjacent downstream SIP entity using SIP requests. The associated > responses are used by SIP entities to indicate willingness to receive > keep-alives. SIP entities that indicate willingness to receive keep- > alives can provide a recommended keep-alive frequency. > >This should be made more explicit. (And can be clarified using the >singular.) > > A SIP entity indicates willingness to send keep-alives towards the > adjacent downstream SIP entity using SIP requests by applying a > "keep" header parameter to the topmost Via (which is the Via that > it inserts). The associated response is used by the adjacent > downstream SIP entity to indicate willingness to receive > keep-alives by applying to that topmost Via a "keep" header > parameter with an integer value. The integer value, if not zero, > indicates the keep-alive frequency that is recommended by the > adjacent downstream SIP entity. > >That gives the outline of the mechanism in one paragraph. During WGLC, there were comments/discussions about removing text, and makin= g it shorter and easier to read. I don't want to start adding text again at= this point, unless something is unclear or wrong. Also, in this case, section 4.1 is a general overview section. The details = on how to indicate willingness to send and receive keep-alives are describe= d in sections 4.3. and 4.4, so there is no need to repeat the same text in = 4.1. -------------- >The 3rd paragraph should probably be expanded to make explicit a >somewhat subtle point: > > The procedures to negotiate usage of keep-alives are identical for > SIP UAs and proxies. However, it is expected that the sender of > keep-alives is the sender of an initial request (REGISTER or > INVITE), which in normal usage is a UA, and so a proxy will not > initiate negotiation for sending keep-alives.=20 The mechanism allows any SIP entity to negotiate sending of keep-alives wit= h its adjacent downstream entity. > Thus, a UA which is > willing to send keep-alives SHOULD always indicate that it is > willing to send keep-alives even if it is not aware of any > necessity of doing so, allowing the adjacent downstream entity to > indicate if it knows that keep-alives are necessary (by responding > with a non-zero value). Similarly, an entity which is willing to > receive keep-alives SHOULD always respond with a keep value of zero > when it is not aware of any necessity for keep-alives, thus leaving > the sender to send keep-alives if the sender is aware of any > necessity to do so. > >Urgh. I suspect that these additions should instead be added to 4.3 >and 4.4 as appropriate. But the mechanism needs to be used correctly >by both entities in order to ensure that keep-alives are sent when >either entity knows that they are needed, and the draft doesn't make >explicit how to do that. I would not like to start adding normative text on how and when entities sh= all use the mechanism, because it might depend on the entity types, and the= environments where they are deployed. However, I guess we could add some general guideline text: "In general, it can be useful for SIP entities to indicate willingness to = send keep-alives, even if they=20 are not aware of any necessity for them to send keep-alives, since the adj= acent downstream SIP entity might=20 have knowledge about the necessity. Similarly, it can be useful for SIP en= tities to indicate willingess to=20 receive keep-alives, even if they are not aware of any necessity for the a= djacent upstream SIP entity to=20 send them." -------------- >Section 4.3 > >It's not clear to me what keep-alives the upstream entity must send >once keep-alives are negotiated. The first paragraph says that the >entity must be able to send both STUN and CRLF keep-alives, but that >seems to be not entirely accurate, as the sender seems to have the >choice of what type of keep-alive to send, and so can choose to send >only one type. I suspect that there are rules elsewhere regarding >what sort of keep-alive is to be sent in what circumstances; if so, >there should be a reference to them. Otherwise, a note should be >added to indicate that the sender has the choice of what sort of >keep-alive to add, and thus does not need to implement both. (The >recipient is required to implement both, of course.) The text refers to RFC 5626 regarding the STUN and CRLF keep-alive messages= , and RFC 5626 defines when each is used. Also, remember that the purpose of the daft is not to change the keep-alive= mechanism in RFC 5626, only to provide a mechanism to explicitly negotiate= the usage of it, so we should not repeat mechanism text that is already de= fined in RFC 5626. BUT, in order to try to make everyone happy, I could add the following sent= ence to the first section of 4.3: "[RFC5626] defines when to use STUN, respectively CRLF, for keep-alives." -------------- >Section 4.4 > >In every place where "frequency" is used, it would be more correct to >use "period". (A frequency is events-per-second, whereas a period is >seconds-per-event.) > >In some place it must be stated that the period is specified in >seconds, which is not done anywhere in the normative part of this >draft. "frequency" is used in Outbound, and I've been asked to use the same termin= ology.=20 I DO agree, however, that it should be indictated that the frequency is pro= vided in seconds. I suggest to change the last sentence of the second paragraph to: "The parameter can contain a recommended keep-alive frequency, given in se= conds, or a zero value." I suggest to add "given in seconds" also to the first paragraph of section = 5: "If a SIP entity receives a SIP response, where its Via header field contains a "keep" parameter with a non-zero value that indicates a recommended keep-alive frequency, given in seconds, it MUST use the=20 procedures defined for the Flow-Timer header field [RFC5626]." -------------- >Section 5 > >In the first paragraph, a few places could be phrased more clearly: > > If a SIP entity receives a SIP response >>whose topmost<< Via > header field contains a "keep" parameter with a non-zero value > >>(which indicates a recommended keep-alive period)<<, it MUST use > the procedures defined >>in [RFC5626], using the value as if it was > the value of the Flow-Timer header field<<. According to >>those<< > procedures, the SIP entity must send keep-alives at least as often > as the indicated recommended keep-alive >>period<<, >>and the SIP > entity should<< send its keep-alives so that the interval between > >>keep-alives<< is randomly distributed between 80% and 100% of the > recommended keep-alive >>period<<. >After this paragraph should be a note saying when the receiving SIP >entity is allowed to assume the connection is dead. Copying from RFC >5626, we could say: > > Following [RFC5626], if a recommended keep-alive period has been > negotiated, the receiving SIP entity may, after not receiving a > keep-alive for that period, consider the flow to be dead. Note > that the entity should wait for a time larger than the period in > order to have a grace period to account for transport delay. I don't think we can use "flow", since that is Outbound specific. Maybe we could simply say: "This specification does not specify actions to take if negotiated keep-al= ives are not received. As defined in [RFC5626], the receiving SIP entity may consider a= connection to be dead in such situations." -------------- >3rd paragraph > >It makes sense that if a single entity inserts both a keep=3Dn parameter >and a Flow-Timer: n header that they should contain the same value. >But that is of no use to (and is not enforceable by) an upstream SIP >entity, since from the upstream entity's point of view, the Flow-Timer >header may have been inserted by an entity further downstream, not its >adjacent downstream entity. That is, an entity expects to see >responses with Flow-Timer and keep=3Dn which disagree, and (I think) >must use the keep value instead of the Flow-Timer value. The text previously said that one MUST NOT insert Flow-Timer if it inserts = keep=3Dn. However, based on WGLC comments from Paul we agreed to remove that restrict= ion, in order for this draft to not make restrictions to Outbound (in cases= where both Outbound and this draft is used). -------------- >Actually, I think the situation is probably more complex than I >realize. The Flow-Timer value seems to apply only between the edge >proxy and the UA, and it it seems that only the UAC should pay >attention to its value. But it's not clear who can add the Flow-Timer >header. It appears that it can only appear in REGISTER responses. It >can be added by the UAS (obviously), but it appears from RFC 5626 >section 5.4 that it can also be added to the response by intermediate >proxies. > >This section needs revision to make clear the interaction between >Flow-Timer and keep=3Dn. I suspect the only workable answer is that an >entity must examine both values (if it supports both mechanisms), >determine whether Flow-Timer applies to this hop, and if so, send >keep-alives according to the minimum of the two specified periods. >Since the two periods might be specified by different entities, there >doesn't seem to be any workable alternative rule. My understanding of 5626 is that only an edge proxy can add the Flow-Timer = header field, since Outbound only defines the usage of keep-alives between = the UA and edge proxy. Outbound itself wouldn't work if multiple entities were allowed to insert F= low-Timer. -------------- >Section 6 > >All examples use STUN keep-alives. It would probably be beneficial to >change one example to use CRLF, or to add a note explaining whether >and when CRLF might be used in the example situations. I can do something like that. >It is possible for two proxies to use this mechanism on a hop between >themselves. Would it be useful to add an example of this? The mechanism allows proxy-to-proxy keep-alives, and there also used to be = an example (or, at least a use-case description) about proxy-to-proxy. Howe= ver, it was removed, because people confused it with proxy-to-proxy heartbe= ats, which is a different thing than keep-alives. Regards, Christer= From pkyzivat@cisco.com Mon Aug 9 07:07:46 2010 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 84F763A6AD6 for ; Mon, 9 Aug 2010 07:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.205 X-Spam-Level: X-Spam-Status: No, score=-110.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8, 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 NpTRACEeCpwY for ; Mon, 9 Aug 2010 07:07:44 -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 250703A6944 for ; Mon, 9 Aug 2010 07:07:44 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANqoX0xAZnwM/2dsb2JhbACgRXGnL5sOgwMIgi8EiTs X-IronPort-AV: E=Sophos;i="4.55,343,1278288000"; d="scan'208";a="145442835" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2010 14:08:18 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o79E8HGe013219; Mon, 9 Aug 2010 14:08:17 GMT Message-ID: <4C600BD1.1030100@cisco.com> Date: Mon, 09 Aug 2010 10:08:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05850CB1D6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850CB1D6@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "WORLEY, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] Review of draft-ietf-sipcore-keep-05 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, 09 Aug 2010 14:07:46 -0000 General comment here: While it is good to remove unnecessary text to simplify the document, if adding a bit of text makes the document clearer, then that should be considered a good thing to do. Thanks, Paul Christer Holmberg wrote: > Hi Dale, > > Thanks for your comments. See inline. > >> I've not been in on the technical discussion, so I can't comment on >> the mechanism design. But the exposition in the draft could be >> improved in a few places. > > Some of your comments ARE related to issues that were discussed during WGLC, and I will indicate it when it occurs. > > > -------------- > > >> The running title is "STUN-keep", which is surely not what is intended. > > I can change that to "keep-alive". > > > -------------- > > >> Section 1.1 >> >> Uses "session" twice, but I think "dialog" is more correct. The >> session (media) contains the RTP, which will probably keep the NAT >> open; the problem is keeping the NAT open for the signaling (dialog). > > I can change "session" to "dialog". > > > -------------- > > >> Section 3 >> >> "Edge proxy" >> >> It's not clear that "edge proxy" has any normative significance in >> this I-D, as this mechanism can be used between any two entities. >> It seems that this definition and the accompanying Note could be >> removed at no loss. (The definition needs revision, also.) > > Section 5 talks about the edge proxy, where it describes that the usage of Flow-Timer is only defined between a UA and an edge proxy, so I think it is useful to have the definition. > > I guess I could also add the following sentence to section 1: > > "In addition, [RFC5626] only allows keep-alives to be negotiated between a UA and an edge proxy, and not between other SIP entities." > > > -------------- > > >> "Keep-alives" >> >> It would help if this definition mentioned that both CRLF and STUN >> keepalives were intended. Also, the phrase "refers to" should be >> removed. E.g.: >> >> Keep-alives: The keep-alive messages defined in SIP Outbound >> [RFC5626], including both "CRLF" and STUN keep-alive messages. > > People have asked me to remove text, and make it shorter and easier to read, so I would not like to start adding text unless something is broken or very unclear. In this case I think that sections 4.3 and 4.4 makes it clear that both CRLF and STUN are included. > > But, I DO agree that "refers to" can be removed: > > "Keep-alives: The keep-alive messages defined in SIP Outbound [RFC5626]." > > -------------- > >> '"keep" parameter' >> >> Strictly speaking, this entry is a description not a definition; the >> phrase '"keep" parameter' identifies the parameter unambiguously. It >> would be better to remove this entry and add its information to >> section 4.1, which needs to be a bit more explicit about the >> mechanism. (See below.) > > The definition text used to be even longer, but parts were removed. However, the terminology is used in the documents, so I think it is good to have it in the definitions, instead of writing "the Via header field "keep" parameter" everywhere. > > > -------------- > > >> Section 4.1, 2nd paragraph is: >> >> SIP entities indicate willingness to send keep-alives towards the >> adjacent downstream SIP entity using SIP requests. The associated >> responses are used by SIP entities to indicate willingness to receive >> keep-alives. SIP entities that indicate willingness to receive keep- >> alives can provide a recommended keep-alive frequency. >> >> This should be made more explicit. (And can be clarified using the >> singular.) >> >> A SIP entity indicates willingness to send keep-alives towards the >> adjacent downstream SIP entity using SIP requests by applying a >> "keep" header parameter to the topmost Via (which is the Via that >> it inserts). The associated response is used by the adjacent >> downstream SIP entity to indicate willingness to receive >> keep-alives by applying to that topmost Via a "keep" header >> parameter with an integer value. The integer value, if not zero, >> indicates the keep-alive frequency that is recommended by the >> adjacent downstream SIP entity. >> >> That gives the outline of the mechanism in one paragraph. > > During WGLC, there were comments/discussions about removing text, and making it shorter and easier to read. I don't want to start adding text again at this point, unless something is unclear or wrong. > > Also, in this case, section 4.1 is a general overview section. The details on how to indicate willingness to send and receive keep-alives are described in sections 4.3. and 4.4, so there is no need to repeat the same text in 4.1. > > > -------------- > > >> The 3rd paragraph should probably be expanded to make explicit a >> somewhat subtle point: >> >> The procedures to negotiate usage of keep-alives are identical for >> SIP UAs and proxies. However, it is expected that the sender of >> keep-alives is the sender of an initial request (REGISTER or >> INVITE), which in normal usage is a UA, and so a proxy will not >> initiate negotiation for sending keep-alives. > > The mechanism allows any SIP entity to negotiate sending of keep-alives with its adjacent downstream entity. > >> Thus, a UA which is >> willing to send keep-alives SHOULD always indicate that it is >> willing to send keep-alives even if it is not aware of any >> necessity of doing so, allowing the adjacent downstream entity to >> indicate if it knows that keep-alives are necessary (by responding >> with a non-zero value). Similarly, an entity which is willing to >> receive keep-alives SHOULD always respond with a keep value of zero >> when it is not aware of any necessity for keep-alives, thus leaving >> the sender to send keep-alives if the sender is aware of any >> necessity to do so. >> >> Urgh. I suspect that these additions should instead be added to 4.3 >> and 4.4 as appropriate. But the mechanism needs to be used correctly >> by both entities in order to ensure that keep-alives are sent when >> either entity knows that they are needed, and the draft doesn't make >> explicit how to do that. > > I would not like to start adding normative text on how and when entities shall use the mechanism, because it might depend on the entity types, and the environments where they are deployed. > > However, I guess we could add some general guideline text: > > "In general, it can be useful for SIP entities to indicate willingness to send keep-alives, even if they > are not aware of any necessity for them to send keep-alives, since the adjacent downstream SIP entity might > have knowledge about the necessity. Similarly, it can be useful for SIP entities to indicate willingess to > receive keep-alives, even if they are not aware of any necessity for the adjacent upstream SIP entity to > send them." > > > -------------- > > >> Section 4.3 >> >> It's not clear to me what keep-alives the upstream entity must send >> once keep-alives are negotiated. The first paragraph says that the >> entity must be able to send both STUN and CRLF keep-alives, but that >> seems to be not entirely accurate, as the sender seems to have the >> choice of what type of keep-alive to send, and so can choose to send >> only one type. I suspect that there are rules elsewhere regarding >> what sort of keep-alive is to be sent in what circumstances; if so, >> there should be a reference to them. Otherwise, a note should be >> added to indicate that the sender has the choice of what sort of >> keep-alive to add, and thus does not need to implement both. (The >> recipient is required to implement both, of course.) > > The text refers to RFC 5626 regarding the STUN and CRLF keep-alive messages, and RFC 5626 defines when each is used. > > Also, remember that the purpose of the daft is not to change the keep-alive mechanism in RFC 5626, only to provide a mechanism to explicitly negotiate the usage of it, so we should not repeat mechanism text that is already defined in RFC 5626. > > BUT, in order to try to make everyone happy, I could add the following sentence to the first section of 4.3: > > "[RFC5626] defines when to use STUN, respectively CRLF, for keep-alives." > > > -------------- > > >> Section 4.4 >> >> In every place where "frequency" is used, it would be more correct to >> use "period". (A frequency is events-per-second, whereas a period is >> seconds-per-event.) >> >> In some place it must be stated that the period is specified in >> seconds, which is not done anywhere in the normative part of this >> draft. > > "frequency" is used in Outbound, and I've been asked to use the same terminology. > > I DO agree, however, that it should be indictated that the frequency is provided in seconds. > > I suggest to change the last sentence of the second paragraph to: > > "The parameter can contain a recommended keep-alive frequency, given in seconds, or a zero value." > > I suggest to add "given in seconds" also to the first paragraph of section 5: > > "If a SIP entity receives a SIP response, where its Via header field > contains a "keep" parameter with a non-zero value that indicates a > recommended keep-alive frequency, given in seconds, it MUST use the > procedures defined for the Flow-Timer header field [RFC5626]." > > > -------------- > > >> Section 5 >> >> In the first paragraph, a few places could be phrased more clearly: >> >> If a SIP entity receives a SIP response >>whose topmost<< Via >> header field contains a "keep" parameter with a non-zero value >> >>(which indicates a recommended keep-alive period)<<, it MUST use >> the procedures defined >>in [RFC5626], using the value as if it was >> the value of the Flow-Timer header field<<. According to >>those<< >> procedures, the SIP entity must send keep-alives at least as often >> as the indicated recommended keep-alive >>period<<, >>and the SIP >> entity should<< send its keep-alives so that the interval between >> >>keep-alives<< is randomly distributed between 80% and 100% of the >> recommended keep-alive >>period<<. > >> After this paragraph should be a note saying when the receiving SIP >> entity is allowed to assume the connection is dead. Copying from RFC >> 5626, we could say: >> >> Following [RFC5626], if a recommended keep-alive period has been >> negotiated, the receiving SIP entity may, after not receiving a >> keep-alive for that period, consider the flow to be dead. Note >> that the entity should wait for a time larger than the period in >> order to have a grace period to account for transport delay. > > I don't think we can use "flow", since that is Outbound specific. > > Maybe we could simply say: > > "This specification does not specify actions to take if negotiated keep-alives are not > received. As defined in [RFC5626], the receiving SIP entity may consider a connection to be > dead in such situations." > > > -------------- > > >> 3rd paragraph >> >> It makes sense that if a single entity inserts both a keep=n parameter >> and a Flow-Timer: n header that they should contain the same value. >> But that is of no use to (and is not enforceable by) an upstream SIP >> entity, since from the upstream entity's point of view, the Flow-Timer >> header may have been inserted by an entity further downstream, not its >> adjacent downstream entity. That is, an entity expects to see >> responses with Flow-Timer and keep=n which disagree, and (I think) >> must use the keep value instead of the Flow-Timer value. > > The text previously said that one MUST NOT insert Flow-Timer if it inserts keep=n. > > However, based on WGLC comments from Paul we agreed to remove that restriction, in order for this draft to not make restrictions to Outbound (in cases where both Outbound and this draft is used). > > > -------------- > > >> Actually, I think the situation is probably more complex than I >> realize. The Flow-Timer value seems to apply only between the edge >> proxy and the UA, and it it seems that only the UAC should pay >> attention to its value. But it's not clear who can add the Flow-Timer >> header. It appears that it can only appear in REGISTER responses. It >> can be added by the UAS (obviously), but it appears from RFC 5626 >> section 5.4 that it can also be added to the response by intermediate >> proxies. >> >> This section needs revision to make clear the interaction between >> Flow-Timer and keep=n. I suspect the only workable answer is that an >> entity must examine both values (if it supports both mechanisms), >> determine whether Flow-Timer applies to this hop, and if so, send >> keep-alives according to the minimum of the two specified periods. >> Since the two periods might be specified by different entities, there >> doesn't seem to be any workable alternative rule. > > My understanding of 5626 is that only an edge proxy can add the Flow-Timer header field, since Outbound only defines the usage of keep-alives between the UA and edge proxy. > > Outbound itself wouldn't work if multiple entities were allowed to insert Flow-Timer. > > > -------------- > > >> Section 6 >> >> All examples use STUN keep-alives. It would probably be beneficial to >> change one example to use CRLF, or to add a note explaining whether >> and when CRLF might be used in the example situations. > > I can do something like that. > >> It is possible for two proxies to use this mechanism on a hop between >> themselves. Would it be useful to add an example of this? > > The mechanism allows proxy-to-proxy keep-alives, and there also used to be an example (or, at least a use-case description) about proxy-to-proxy. However, it was removed, because people confused it with proxy-to-proxy heartbeats, which is a different thing than keep-alives. > > > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Mon Aug 9 10:10:57 2010 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 976EB3A6B13 for ; Mon, 9 Aug 2010 10:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, J_CHICKENPOX_41=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 i1NjjF7TZQjG for ; Mon, 9 Aug 2010 10:10:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CF3383A6B11 for ; Mon, 9 Aug 2010 10:10:54 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-90-4c6036bf0d1a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BE.C7.06895.FB6306C4; Mon, 9 Aug 2010 19:11:27 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 9 Aug 2010 19:11:27 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Mon, 9 Aug 2010 19:08:24 +0200 Thread-Topic: [sipcore] Review of draft-ietf-sipcore-keep-05 Thread-Index: Acs3zFKCNmY4bvg4QA+WGPV1h0Rl2AAGSemP Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850B5C57@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850CB1D6@ESESSCMS0356.eemea.ericsson.se>, <4C600BD1.1030100@cisco.com> In-Reply-To: <4C600BD1.1030100@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-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] Review of draft-ietf-sipcore-keep-05 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, 09 Aug 2010 17:10:57 -0000 Hi, >General comment here: > >While it is good to remove unnecessary text to simplify the document, >if adding a bit of text makes the document clearer, then that should be >considered a good thing to do. Of course.=20 But, in this case I think it is much about duplicating text that already ex= ists elsewhere in the document, which I don't think is needed. And, from my experience with IESG, they are very likely going to ask for su= ch duplications to be removed anyway. Regards, Christer Christer Holmberg wrote: > Hi Dale, > > Thanks for your comments. See inline. > >> I've not been in on the technical discussion, so I can't comment on >> the mechanism design. But the exposition in the draft could be >> improved in a few places. > > Some of your comments ARE related to issues that were discussed during WG= LC, and I will indicate it when it occurs. > > > -------------- > > >> The running title is "STUN-keep", which is surely not what is intended. > > I can change that to "keep-alive". > > > -------------- > > >> Section 1.1 >> >> Uses "session" twice, but I think "dialog" is more correct. The >> session (media) contains the RTP, which will probably keep the NAT >> open; the problem is keeping the NAT open for the signaling (dialog). > > I can change "session" to "dialog". > > > -------------- > > >> Section 3 >> >> "Edge proxy" >> >> It's not clear that "edge proxy" has any normative significance in >> this I-D, as this mechanism can be used between any two entities. >> It seems that this definition and the accompanying Note could be >> removed at no loss. (The definition needs revision, also.) > > Section 5 talks about the edge proxy, where it describes that the usage o= f Flow-Timer is only defined between a UA and an edge proxy, so I think it = is useful to have the definition. > > I guess I could also add the following sentence to section 1: > > "In addition, [RFC5626] only allows keep-alives to be negotiated be= tween a UA and an edge proxy, and not between other SIP entities." > > > -------------- > > >> "Keep-alives" >> >> It would help if this definition mentioned that both CRLF and STUN >> keepalives were intended. Also, the phrase "refers to" should be >> removed. E.g.: >> >> Keep-alives: The keep-alive messages defined in SIP Outbound >> [RFC5626], including both "CRLF" and STUN keep-alive messages. > > People have asked me to remove text, and make it shorter and easier to re= ad, so I would not like to start adding text unless something is broken or = very unclear. In this case I think that sections 4.3 and 4.4 makes it clear= that both CRLF and STUN are included. > > But, I DO agree that "refers to" can be removed: > > "Keep-alives: The keep-alive messages defined in SIP Outbound [RFC= 5626]." > > -------------- > >> '"keep" parameter' >> >> Strictly speaking, this entry is a description not a definition; the >> phrase '"keep" parameter' identifies the parameter unambiguously. It >> would be better to remove this entry and add its information to >> section 4.1, which needs to be a bit more explicit about the >> mechanism. (See below.) > > The definition text used to be even longer, but parts were removed. Howev= er, the terminology is used in the documents, so I think it is good to have= it in the definitions, instead of writing "the Via header field "keep" par= ameter" everywhere. > > > -------------- > > >> Section 4.1, 2nd paragraph is: >> >> SIP entities indicate willingness to send keep-alives towards the >> adjacent downstream SIP entity using SIP requests. The associated >> responses are used by SIP entities to indicate willingness to receive >> keep-alives. SIP entities that indicate willingness to receive keep- >> alives can provide a recommended keep-alive frequency. >> >> This should be made more explicit. (And can be clarified using the >> singular.) >> >> A SIP entity indicates willingness to send keep-alives towards the >> adjacent downstream SIP entity using SIP requests by applying a >> "keep" header parameter to the topmost Via (which is the Via that >> it inserts). The associated response is used by the adjacent >> downstream SIP entity to indicate willingness to receive >> keep-alives by applying to that topmost Via a "keep" header >> parameter with an integer value. The integer value, if not zero, >> indicates the keep-alive frequency that is recommended by the >> adjacent downstream SIP entity. >> >> That gives the outline of the mechanism in one paragraph. > > During WGLC, there were comments/discussions about removing text, and mak= ing it shorter and easier to read. I don't want to start adding text again = at this point, unless something is unclear or wrong. > > Also, in this case, section 4.1 is a general overview section. The detail= s on how to indicate willingness to send and receive keep-alives are descri= bed in sections 4.3. and 4.4, so there is no need to repeat the same text i= n 4.1. > > > -------------- > > >> The 3rd paragraph should probably be expanded to make explicit a >> somewhat subtle point: >> >> The procedures to negotiate usage of keep-alives are identical for >> SIP UAs and proxies. However, it is expected that the sender of >> keep-alives is the sender of an initial request (REGISTER or >> INVITE), which in normal usage is a UA, and so a proxy will not >> initiate negotiation for sending keep-alives. > > The mechanism allows any SIP entity to negotiate sending of keep-alives w= ith its adjacent downstream entity. > >> Thus, a UA which is >> willing to send keep-alives SHOULD always indicate that it is >> willing to send keep-alives even if it is not aware of any >> necessity of doing so, allowing the adjacent downstream entity to >> indicate if it knows that keep-alives are necessary (by responding >> with a non-zero value). Similarly, an entity which is willing to >> receive keep-alives SHOULD always respond with a keep value of zero >> when it is not aware of any necessity for keep-alives, thus leaving >> the sender to send keep-alives if the sender is aware of any >> necessity to do so. >> >> Urgh. I suspect that these additions should instead be added to 4.3 >> and 4.4 as appropriate. But the mechanism needs to be used correctly >> by both entities in order to ensure that keep-alives are sent when >> either entity knows that they are needed, and the draft doesn't make >> explicit how to do that. > > I would not like to start adding normative text on how and when entities = shall use the mechanism, because it might depend on the entity types, and t= he environments where they are deployed. > > However, I guess we could add some general guideline text: > > "In general, it can be useful for SIP entities to indicate willingn= ess to send keep-alives, even if they > are not aware of any necessity for them to send keep-alives, since = the adjacent downstream SIP entity might > have knowledge about the necessity. Similarly, it can be useful for= SIP entities to indicate willingess to > receive keep-alives, even if they are not aware of any necessity fo= r the adjacent upstream SIP entity to > send them." > > > -------------- > > >> Section 4.3 >> >> It's not clear to me what keep-alives the upstream entity must send >> once keep-alives are negotiated. The first paragraph says that the >> entity must be able to send both STUN and CRLF keep-alives, but that >> seems to be not entirely accurate, as the sender seems to have the >> choice of what type of keep-alive to send, and so can choose to send >> only one type. I suspect that there are rules elsewhere regarding >> what sort of keep-alive is to be sent in what circumstances; if so, >> there should be a reference to them. Otherwise, a note should be >> added to indicate that the sender has the choice of what sort of >> keep-alive to add, and thus does not need to implement both. (The >> recipient is required to implement both, of course.) > > The text refers to RFC 5626 regarding the STUN and CRLF keep-alive messag= es, and RFC 5626 defines when each is used. > > Also, remember that the purpose of the daft is not to change the keep-ali= ve mechanism in RFC 5626, only to provide a mechanism to explicitly negotia= te the usage of it, so we should not repeat mechanism text that is already = defined in RFC 5626. > > BUT, in order to try to make everyone happy, I could add the following se= ntence to the first section of 4.3: > > "[RFC5626] defines when to use STUN, respectively CRLF, for keep-al= ives." > > > -------------- > > >> Section 4.4 >> >> In every place where "frequency" is used, it would be more correct to >> use "period". (A frequency is events-per-second, whereas a period is >> seconds-per-event.) >> >> In some place it must be stated that the period is specified in >> seconds, which is not done anywhere in the normative part of this >> draft. > > "frequency" is used in Outbound, and I've been asked to use the same term= inology. > > I DO agree, however, that it should be indictated that the frequency is p= rovided in seconds. > > I suggest to change the last sentence of the second paragraph to: > > "The parameter can contain a recommended keep-alive frequency, give= n in seconds, or a zero value." > > I suggest to add "given in seconds" also to the first paragraph of sectio= n 5: > > "If a SIP entity receives a SIP response, where its Via header fiel= d > contains a "keep" parameter with a non-zero value that indicates a > recommended keep-alive frequency, given in seconds, it MUST use the > procedures defined for the Flow-Timer header field [RFC5626]." > > > -------------- > > >> Section 5 >> >> In the first paragraph, a few places could be phrased more clearly: >> >> If a SIP entity receives a SIP response >>whose topmost<< Via >> header field contains a "keep" parameter with a non-zero value >> >>(which indicates a recommended keep-alive period)<<, it MUST use >> the procedures defined >>in [RFC5626], using the value as if it was >> the value of the Flow-Timer header field<<. According to >>those<< >> procedures, the SIP entity must send keep-alives at least as often >> as the indicated recommended keep-alive >>period<<, >>and the SIP >> entity should<< send its keep-alives so that the interval between >> >>keep-alives<< is randomly distributed between 80% and 100% of the >> recommended keep-alive >>period<<. > >> After this paragraph should be a note saying when the receiving SIP >> entity is allowed to assume the connection is dead. Copying from RFC >> 5626, we could say: >> >> Following [RFC5626], if a recommended keep-alive period has been >> negotiated, the receiving SIP entity may, after not receiving a >> keep-alive for that period, consider the flow to be dead. Note >> that the entity should wait for a time larger than the period in >> order to have a grace period to account for transport delay. > > I don't think we can use "flow", since that is Outbound specific. > > Maybe we could simply say: > > "This specification does not specify actions to take if negotiated = keep-alives are not > received. As defined in [RFC5626], the receiving SIP entity may con= sider a connection to be > dead in such situations." > > > -------------- > > >> 3rd paragraph >> >> It makes sense that if a single entity inserts both a keep=3Dn parameter >> and a Flow-Timer: n header that they should contain the same value. >> But that is of no use to (and is not enforceable by) an upstream SIP >> entity, since from the upstream entity's point of view, the Flow-Timer >> header may have been inserted by an entity further downstream, not its >> adjacent downstream entity. That is, an entity expects to see >> responses with Flow-Timer and keep=3Dn which disagree, and (I think) >> must use the keep value instead of the Flow-Timer value. > > The text previously said that one MUST NOT insert Flow-Timer if it insert= s keep=3Dn. > > However, based on WGLC comments from Paul we agreed to remove that restri= ction, in order for this draft to not make restrictions to Outbound (in cas= es where both Outbound and this draft is used). > > > -------------- > > >> Actually, I think the situation is probably more complex than I >> realize. The Flow-Timer value seems to apply only between the edge >> proxy and the UA, and it it seems that only the UAC should pay >> attention to its value. But it's not clear who can add the Flow-Timer >> header. It appears that it can only appear in REGISTER responses. It >> can be added by the UAS (obviously), but it appears from RFC 5626 >> section 5.4 that it can also be added to the response by intermediate >> proxies. >> >> This section needs revision to make clear the interaction between >> Flow-Timer and keep=3Dn. I suspect the only workable answer is that an >> entity must examine both values (if it supports both mechanisms), >> determine whether Flow-Timer applies to this hop, and if so, send >> keep-alives according to the minimum of the two specified periods. >> Since the two periods might be specified by different entities, there >> doesn't seem to be any workable alternative rule. > > My understanding of 5626 is that only an edge proxy can add the Flow-Time= r header field, since Outbound only defines the usage of keep-alives betwee= n the UA and edge proxy. > > Outbound itself wouldn't work if multiple entities were allowed to insert= Flow-Timer. > > > -------------- > > >> Section 6 >> >> All examples use STUN keep-alives. It would probably be beneficial to >> change one example to use CRLF, or to add a note explaining whether >> and when CRLF might be used in the example situations. > > I can do something like that. > >> It is possible for two proxies to use this mechanism on a hop between >> themselves. Would it be useful to add an example of this? > > The mechanism allows proxy-to-proxy keep-alives, and there also used to b= e an example (or, at least a use-case description) about proxy-to-proxy. Ho= wever, it was removed, because people confused it with proxy-to-proxy heart= beats, which is a different thing than keep-alives. > > > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >= From pkyzivat@cisco.com Mon Aug 9 15:34:28 2010 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 4D51328C148 for ; Mon, 9 Aug 2010 15:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.502 X-Spam-Level: X-Spam-Status: No, score=-110.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 1+fKicqCs7CX for ; Mon, 9 Aug 2010 15:33:04 -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 8EC343A6878 for ; Mon, 9 Aug 2010 15:31:17 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL4eYExAZnwM/2dsb2JhbACgUXGoQptfhToEiTs X-IronPort-AV: E=Sophos;i="4.55,345,1278288000"; d="scan'208";a="145472574" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2010 22:31:50 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o79MVoN7006139; Mon, 9 Aug 2010 22:31:50 GMT Message-ID: <4C6081DB.6000504@cisco.com> Date: Mon, 09 Aug 2010 18:31:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se>, <4C5821D6.6030907@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3B@ESESSCMS0356.eemea.ericsson.se>, <4C583887.8030700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850B5C3E@ESESSCMS0356.eemea.ericsson.se> <4C583FD3.6060901@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850CA84A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850CA84A@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Peter Musgrave Subject: Re: [sipcore] draft-ietf-sipcore-keep - New draft version 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, 09 Aug 2010 22:34:29 -0000 Christer, [speaking as individual] I have reviewed the new version. The change in use of upstream and downstream has worked out well - it now seems understandable and not upside down. *Except* I think you missed changing one place - in 1.1: In some cases a User Agent Client (UAC) does not register itself before it establishes a session, but in order to maintain NAT bindings open during the session it still needs to be able to negotiate sending of keep-alives towards its adjacent upstream SIP entity. A typical example is an emergency call, where a registration is not always required in order to make the call. In that "upstream" should be "donwstream". But I still think there are problems with the rules for routing messages so as to take advantage of the keep-alives while avoiding doing anything improper. The intro lists three cases, but I think two of them (1.1 and 1.3) are describing the same situation. So we get two cases from there: WITH-OUTBOUND: no register, dialog establishing request, outbound *is* in use. There is need of negotiating keep-alive use that isn't negotiated as part of outbound WITHOUT-OUTBOUND: outbound is not supported and so not used, but keep-alives still desired. Includes both REGISTER and Dialog-establishing sub-cases. In the WITH-OUTBOUND case: outbound results in the negotiation of keep-alives on the last hop to the UA. So IIUC, the use of keep is to negotiate keep-alives on other hops along the path. 5626 specifies the procedures for selecting/reusing the flow for subsequent requests in dialog for the hop it is concerned with. It does not do so for any other hop. keep-05 has text added to 4.4 for this case, but I don't think it is right. This is a case that could be covered, in part, by 5923 (connect-reuse). In the TLS case where 5923 allows bidirectional use of a connection, the keep-alive mechanism is complementary. But that is no good for TCP or UDP. The security concerns that prevented 5923 from permitting bidirectional use of TCP are also reasons it can't in general be used here. It should arguably be ok to use TCP and UDP bidirectionally here as long as the usage is restricted to in-dialog requests. But its going to take some additional text to limit it this way and explain the reason that security is not compromised. In the WITHOUT-OUTBOUND case: You can't fall back on outbound to give any guidance on when to use a flow and when not. In the dialog-establishing case, the rules that apply to the non-last hops in the WITH-OUTBOUND case should also apply here, even to the last hop. In the REGISTER case it gets harder. The problem is that you want to support new outbound out-of-dialog requests. If you have a TLS connection, then 5923 tells you when you can do it. Without that, the reuse of the flow must be tied to the registration in some way. I know you want this for IMS which has its own form of secure connection. But you are going to have to find some way to specify it here that will survive security considerations scrutiny. I don't know what that might be. In any case, I suspect you need to reinstate the references to 5923 to make this all work. I'm still hoping to get comments from an outbound expert here. They might be able to put all this stuff in context better than I can. Thanks, Paul Christer Holmberg wrote: > (Private) > > Hi, > > Based on your WGLC comments/discussions, I have put together a new version draft. > > It can be found at: > > http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-keep-05pre.txt > > Please check whether your issues have been addressed. > > Please note that I have now "switched" downstream and upstream, and suggested definition text for those. > > Please also note that I for now have removed section 6, regarding overlapping with the connect-reuse spec. > > Regards, > > Christer From dworley@avaya.com Mon Aug 9 18:22:31 2010 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 20BCC3A6894 for ; Mon, 9 Aug 2010 18:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, 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 bXC9kWgwFkHh for ; Mon, 9 Aug 2010 18:22:29 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 601CF3A68E6 for ; Mon, 9 Aug 2010 18:22:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,345,1278302400"; d="scan'208";a="29023060" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 09 Aug 2010 21:23:03 -0400 X-IronPort-AV: E=Sophos;i="4.55,345,1278302400"; d="scan'208";a="491554537" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Aug 2010 21:22:28 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 9 Aug 2010 21:22:28 -0400 From: "WORLEY, Dale R (Dale)" To: Christer Holmberg , "sipcore@ietf.org" Date: Mon, 9 Aug 2010 21:22:27 -0400 Thread-Topic: Review of draft-ietf-sipcore-keep-05 Thread-Index: AQHLNxQfbKRBGdvoDEWm/nBr9CW465LX0d7FgAIKXi0= Message-ID: References: , <7F2072F1E0DE894DA4B517B93C6A05850CB1D6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850CB1D6@ESESSCMS0356.eemea.ericsson.se> 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 Subject: Re: [sipcore] Review of draft-ietf-sipcore-keep-05 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, 10 Aug 2010 01:22:31 -0000 Only the items for which I have further comment: > From: Christer Holmberg [christer.holmberg@ericsson.com] One general point that might be worth adding to section 1 is, "This specification is an extension of SIP Outbound and is to be read based on [RFC5626]." A considerable number of my comments and confusions would have been eliminated had I understood that this draft can only be effectively read given an understanding of 5626. > >Section 3 > > > >"Edge proxy" > > > >It's not clear that "edge proxy" has any normative significance in > >this I-D, as this mechanism can be used between any two entities. > >It seems that this definition and the accompanying Note could be > >removed at no loss. (The definition needs revision, also.) >=20 > Section 5 talks about the edge proxy, where it describes that the > usage of Flow-Timer is only defined between a UA and an edge proxy, > so I think it is useful to have the definition. OK, I can see the usefulness of that. Edge proxy: As defined in [RFC5626], a SIP proxy that is located topologically between the registering User Agent (UA) and the Authoritative Proxy. One change that I think would have helped me avoid confusion would be to change "a SIP proxy" to "any SIP proxy". Because naively I think of "edge proxy" as meaning only the one proxy closest to the UA; but in Outbound, it refers to any proxy between the Authoritative Proxy and the UA, there can be many of them for a single UA. The phrase "any SIP proxy" warns me that there might be more than one in a particular UA/Registrar connection. OTOH, if we warn the reader to read RFC 5626 first, that probably doesn't matter. > I guess I could also add the following sentence to section 1: >=20 > "In addition, [RFC5626] only allows keep-alives to be > negotiated between a UA and an edge proxy, and not between other > SIP entities." That certainly is a significant restriction on Outbound. > >'"keep" parameter' > > > >Strictly speaking, this entry is a description not a definition; the > >phrase '"keep" parameter' identifies the parameter unambiguously. It > >would be better to remove this entry and add its information to > >section 4.1, which needs to be a bit more explicit about the > >mechanism. (See below.) >=20 > The definition text used to be even longer, but parts were > removed. However, the terminology is used in the documents, so I > think it is good to have it in the definitions, instead of writing > "the Via header field "keep" parameter" everywhere. OK, now I see what the point of the definition is. In that case, you can say: "keep" parameter: The "keep" header field parameter of the topmost Via header of a SIP message. That defines the phrase exactly; it's shorter (which people seem to want); and it removes the text which describes how the parameter is used and leaves only the definition itself. > > A SIP entity indicates willingness to send keep-alives towards the > > adjacent downstream SIP entity using SIP requests by applying a > > "keep" header parameter to the topmost Via (which is the Via that > > it inserts). The associated response is used by the adjacent > > downstream SIP entity to indicate willingness to receive > > keep-alives by applying to that topmost Via a "keep" header > > parameter with an integer value. The integer value, if not zero, > > indicates the keep-alive frequency that is recommended by the > > adjacent downstream SIP entity. > > > >That gives the outline of the mechanism in one paragraph. >=20 > During WGLC, there were comments/discussions about removing text, > and making it shorter and easier to read. I don't want to start > adding text again at this point, unless something is unclear or > wrong. >=20 > Also, in this case, section 4.1 is a general overview section. The > details on how to indicate willingness to send and receive > keep-alives are described in sections 4.3. and 4.4, so there is > no need to repeat the same text in 4.1. The current text was unclear to me in that while it said that keepalives were negotiated via requests and responses it gave no hint of *how*. If brevity is important, I would mention the specific use of "keep" in the request and response, and leave the discussion of frequency to the more detailed sections. > I would not like to start adding normative text on how and when > entities shall use the mechanism, because it might depend on the > entity types, and the environments where they are deployed. >=20 > However, I guess we could add some general guideline text: >=20 > "In general, it can be useful for SIP entities to indicate > willingness to send keep-alives, even if they are not aware > of any necessity for them to send keep-alives, since the > adjacent downstream SIP entity might have knowledge about > the necessity. Similarly, it can be useful for SIP entities > to indicate willingness to receive keep-alives, even if they > are not aware of any necessity for the adjacent upstream SIP > entity to send them." I would add a final clause to the second sentence like the final clause of the first sentence, "... since the adjacent upstream SIP entity might have knowledge about the necessity." I agree that this should not be normative, but it seems to me to be something that the reader should be warned about, since it's not at all obvious at first reading that both devices should negotiate the possibility of keep-alives even if nether knows that they are needed. > The text refers to RFC 5626 regarding the STUN and CRLF keep-alive > messages, and RFC 5626 defines when each is used. > > Also, remember that the purpose of the daft is not to change the > keep-alive mechanism in RFC 5626, only to provide a mechanism to > explicitly negotiate the usage of it, so we should not repeat > mechanism text that is already defined in RFC 5626. >=20 > BUT, in order to try to make everyone happy, I could add the following se= ntence to the first section of 4.3: >=20 > "[RFC5626] defines when to use STUN, respectively CRLF, for keep-= alives." This is an example of where this draft is really an extension of RFC 5626, which is something you understand implicitly and I didn't know. I think that confusion can be cured by the note in section 1 that I mention above. > Maybe we could simply say: >=20 > "This specification does not specify actions to take if > negotiated keep-alives are not received. As defined in > [RFC5626], the receiving SIP entity may consider a > connection to be dead in such situations." Again, this draft is just a way of activating the mechanism defined in 5626= . > My understanding of 5626 is that only an edge proxy can add the > Flow-Timer header field, since Outbound only defines the usage of > keep-alives between the UA and edge proxy. >=20 > Outbound itself wouldn't work if multiple entities were allowed to > insert Flow-Timer. The critical thing is that since only an edge proxy, and only a *first* edge proxy, can add a Flow-Timer header, you will never have an entity adding "keep=3Dn" to a response which *already* has a Flow-Timer header, although it might add both "keep=3Dn" and Flow-Timer to a response. If one hasn't read 5626, this isn't obvious. > The mechanism allows proxy-to-proxy keep-alives, and there also used > to be an example (or, at least a use-case description) about > proxy-to-proxy. However, it was removed, because people confused it > with proxy-to-proxy heartbeats, which is a different thing than > keep-alives. Yes, it probably isn't worth the confusion to describe the proxy-to-proxy case, which will probably be uncommon. Dale From christer.holmberg@ericsson.com Mon Aug 9 22:19:00 2010 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 86E063A6A08 for ; Mon, 9 Aug 2010 22:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=-0.886, 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 Fy+BV9GsSwFa for ; Mon, 9 Aug 2010 22:18:50 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B6B233A6885 for ; Mon, 9 Aug 2010 22:18:49 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-b5-4c60e15a6666 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 06.FF.06895.A51E06C4; Tue, 10 Aug 2010 07:19:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 10 Aug 2010 07:19:22 +0200 From: Christer Holmberg To: "WORLEY, Dale R (Dale)" , "sipcore@ietf.org" Date: Tue, 10 Aug 2010 07:19:20 +0200 Thread-Topic: Review of draft-ietf-sipcore-keep-05 Thread-Index: AQHLNxQfbKRBGdvoDEWm/nBr9CW465LX0d7FgAIKXi2AAEZY8A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585111889@ESESSCMS0356.eemea.ericsson.se> References: , <7F2072F1E0DE894DA4B517B93C6A05850CB1D6@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Review of draft-ietf-sipcore-keep-05 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, 10 Aug 2010 05:19:03 -0000 Hi Dale,=20 >Only the items for which I have further comment: >=20 >>From: Christer Holmberg [christer.holmberg@ericsson.com] >=20 >One general point that might be worth adding to section 1 is,=20 >"This specification is an extension of SIP Outbound and is to=20 >be read based on [RFC5626]." A considerable number of my=20 >comments and confusions would have been eliminated had I=20 >understood that this draft can only be effectively read given=20 >an understanding of 5626. I think *extension* is the wrong wording. The draft defines a negotiation mechanism for the keep-alive mechanism, whi= ch is defined in the Outbound spec (at some point I think we said that the = keep-alive mechanism should have been in a separate spec from the rest of O= utbound in the first place, but it was too late to make that change at that= point).=20 Would it be more clear if I added the following sentence to section 1? "The details of the keep-alive mechanisms are described in [RFC 5626]." Regards, Christer >=20 > > >Section 3 > > > > > >"Edge proxy" > > > > > >It's not clear that "edge proxy" has any normative significance in=20 > > >this I-D, as this mechanism can be used between any two entities. > > >It seems that this definition and the accompanying Note could be=20 > > >removed at no loss. (The definition needs revision, also.) > >=20 > > Section 5 talks about the edge proxy, where it describes that the=20 > > usage of Flow-Timer is only defined between a UA and an=20 > edge proxy, so=20 > > I think it is useful to have the definition. >=20 > OK, I can see the usefulness of that. >=20 > Edge proxy: As defined in [RFC5626], a SIP proxy that is located > topologically between the registering User Agent (UA) and the > Authoritative Proxy. >=20 > One change that I think would have helped me avoid confusion=20 > would be to change "a SIP proxy" to "any SIP proxy". Because=20 > naively I think of "edge proxy" as meaning only the one proxy=20 > closest to the UA; but in Outbound, it refers to any proxy=20 > between the Authoritative Proxy and the UA, there can be many=20 > of them for a single UA. The phrase "any SIP proxy" warns me=20 > that there might be more than one in a particular=20 > UA/Registrar connection. OTOH, if we warn the reader to read=20 > RFC 5626 first, that probably doesn't matter. >=20 > > I guess I could also add the following sentence to section 1: > >=20 > > "In addition, [RFC5626] only allows keep-alives to be > > negotiated between a UA and an edge proxy, and not=20 > between other > > SIP entities." >=20 > That certainly is a significant restriction on Outbound. >=20 > > >'"keep" parameter' > > > > > >Strictly speaking, this entry is a description not a=20 > definition; the=20 > > >phrase '"keep" parameter' identifies the parameter=20 > unambiguously. It=20 > > >would be better to remove this entry and add its information to=20 > > >section 4.1, which needs to be a bit more explicit about the=20 > > >mechanism. (See below.) > >=20 > > The definition text used to be even longer, but parts were removed.=20 > > However, the terminology is used in the documents, so I think it is=20 > > good to have it in the definitions, instead of writing "the=20 > Via header=20 > > field "keep" parameter" everywhere. >=20 > OK, now I see what the point of the definition is. In that=20 > case, you can say: >=20 > "keep" parameter: The "keep" header field parameter of the topmost > Via header of a SIP message. >=20 > That defines the phrase exactly; it's shorter (which people=20 > seem to want); and it removes the text which describes how=20 > the parameter is used and leaves only the definition itself. >=20 > > > A SIP entity indicates willingness to send keep-alives=20 > towards the > > > adjacent downstream SIP entity using SIP requests by applying a > > > "keep" header parameter to the topmost Via (which is=20 > the Via that > > > it inserts). The associated response is used by the adjacent > > > downstream SIP entity to indicate willingness to receive =20 > > > keep-alives by applying to that topmost Via a "keep" header > > > parameter with an integer value. The integer value, if=20 > not zero, > > > indicates the keep-alive frequency that is recommended by the > > > adjacent downstream SIP entity. > > > > > >That gives the outline of the mechanism in one paragraph. > >=20 > > During WGLC, there were comments/discussions about removing=20 > text, and=20 > > making it shorter and easier to read. I don't want to start adding=20 > > text again at this point, unless something is unclear or wrong. > >=20 > > Also, in this case, section 4.1 is a general overview section. The=20 > > details on how to indicate willingness to send and receive=20 > keep-alives=20 > > are described in sections 4.3. and 4.4, so there is no need=20 > to repeat=20 > > the same text in 4.1. >=20 > The current text was unclear to me in that while it said that=20 > keepalives were negotiated via requests and responses it gave=20 > no hint of *how*. If brevity is important, I would mention=20 > the specific use of "keep" in the request and response, and=20 > leave the discussion of frequency to the more detailed sections. >=20 > > I would not like to start adding normative text on how and when=20 > > entities shall use the mechanism, because it might depend on the=20 > > entity types, and the environments where they are deployed. > >=20 > > However, I guess we could add some general guideline text: > >=20 > > "In general, it can be useful for SIP entities to indicate > > willingness to send keep-alives, even if they are not aware > > of any necessity for them to send keep-alives, since the > > adjacent downstream SIP entity might have knowledge about > > the necessity. Similarly, it can be useful for SIP entities > > to indicate willingness to receive keep-alives, even if they > > are not aware of any necessity for the adjacent upstream SIP > > entity to send them." >=20 > I would add a final clause to the second sentence like the=20 > final clause of the first sentence, "... since the adjacent=20 > upstream SIP entity might have knowledge about the=20 > necessity." I agree that this should not be normative, but=20 > it seems to me to be something that the reader should be=20 > warned about, since it's not at all obvious at first reading=20 > that both devices should negotiate the possibility of=20 > keep-alives even if nether knows that they are needed. >=20 > > The text refers to RFC 5626 regarding the STUN and CRLF keep-alive=20 > > messages, and RFC 5626 defines when each is used. > > > > Also, remember that the purpose of the daft is not to change the=20 > > keep-alive mechanism in RFC 5626, only to provide a mechanism to=20 > > explicitly negotiate the usage of it, so we should not repeat=20 > > mechanism text that is already defined in RFC 5626. > >=20 > > BUT, in order to try to make everyone happy, I could add=20 > the following sentence to the first section of 4.3: > >=20 > > "[RFC5626] defines when to use STUN, respectively=20 > CRLF, for keep-alives." >=20 > This is an example of where this draft is really an extension=20 > of RFC 5626, which is something you understand implicitly and=20 > I didn't know. > I think that confusion can be cured by the note in section 1=20 > that I mention above. >=20 > > Maybe we could simply say: > >=20 > > "This specification does not specify actions to take if > > negotiated keep-alives are not received. As defined in > > [RFC5626], the receiving SIP entity may consider a > > connection to be dead in such situations." >=20 > Again, this draft is just a way of activating the mechanism=20 > defined in 5626. >=20 > > My understanding of 5626 is that only an edge proxy can add the=20 > > Flow-Timer header field, since Outbound only defines the usage of=20 > > keep-alives between the UA and edge proxy. > >=20 > > Outbound itself wouldn't work if multiple entities were allowed to=20 > > insert Flow-Timer. >=20 > The critical thing is that since only an edge proxy, and only a > *first* edge proxy, can add a Flow-Timer header, you will=20 > never have an entity adding "keep=3Dn" to a response which=20 > *already* has a Flow-Timer header, although it might add both=20 > "keep=3Dn" and Flow-Timer to a response. If one hasn't read=20 > 5626, this isn't obvious. >=20 > > The mechanism allows proxy-to-proxy keep-alives, and there=20 > also used=20 > > to be an example (or, at least a use-case description) about=20 > > proxy-to-proxy. However, it was removed, because people confused it=20 > > with proxy-to-proxy heartbeats, which is a different thing than=20 > > keep-alives. >=20 > Yes, it probably isn't worth the confusion to describe the=20 > proxy-to-proxy case, which will probably be uncommon. >=20 > Dale > = From john.elwell@siemens-enterprise.com Thu Aug 12 01:20:45 2010 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 5135228C102 for ; Thu, 12 Aug 2010 01:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.763 X-Spam-Level: X-Spam-Status: No, score=-102.763 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, 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 RgWjaYmfezsP for ; Thu, 12 Aug 2010 01:20:44 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 421B428C0DE for ; Thu, 12 Aug 2010 01:20:43 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1146676 for sipcore@ietf.org; Thu, 12 Aug 2010 10:21:20 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 5699123F0278 for ; Thu, 12 Aug 2010 10:21:20 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 12 Aug 2010 10:21:20 +0200 From: "Elwell, John" To: "sipcore@ietf.org" Date: Thu, 12 Aug 2010 10:21:19 +0200 Thread-Topic: Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5g== Message-ID: 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 Subject: [sipcore] Questions on location conveyance and dereferencing 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, 12 Aug 2010 08:20:45 -0000 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, SIP and SIPS URI= schemes for LbyR. For SIP and SIPS, there seems to be an absence of specif= ication of what event package to use when submitting a SIP or SIPS SUBSCRIB= E request for dereference purposes. If it is not defined in this specificat= ion, where is it defined? 2. Concerning PRES-URIs, we have the following text in 4.6: "If a location URI is included in a SIP request, it MUST be a SIP-,=20 SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if=20 the resulting resolution resolves to a SIP: or SIPS: URI, this=20 section applies." The words "this section applies" are rather strange, because there is littl= e else in this section. Maybe in a previous iteration there was more inform= ation here (on how to use a SIP/SIPS URI for dereference purposes). As thin= gs stand, the absence of information on how to resolve a SIP- or SIPS-URI a= pplies also to PRES-URIs. 3. Also there is nothing to say what to do if the PRES URI fails to resolve= to a SIP or SIPS URI. 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited above seems to pre= clude the addition of future URI schemes, which seems to be in conflict wit= h 8.6 (registry establishment for location URIs). John= From James.Winterbottom@andrew.com Thu Aug 12 01:27:09 2010 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 A4B9A3A69F0 for ; Thu, 12 Aug 2010 01:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=-0.856, 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 0ML0d494m2g8 for ; Thu, 12 Aug 2010 01:27:08 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 0BE763A69C3 for ; Thu, 12 Aug 2010 01:27:08 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:33291 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S30152371Ab0HLI1o convert rfc822-to-8bit (ORCPT ); Thu, 12 Aug 2010 03:27:44 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 12 Aug 2010 03:27:44 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 12 Aug 2010 16:27:40 +0800 From: "Winterbottom, James" To: "Elwell, John" , "sipcore@ietf.org" Date: Thu, 12 Aug 2010 16:26:33 +0800 Thread-Topic: Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKV Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com> References: 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: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 12 Aug 2010 08:27:09 -0000 Hi John, I think you could use this as a basic location subscription: http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 There is already a lot of protest against point 2, and I believe that this is going to be fixed. Cheers James ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] Sent: Thursday, August 12, 2010 3:21 AM To: sipcore@ietf.org Subject: [sipcore] Questions on location conveyance and dereferencing 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there seems to be an absence of specification of what event package to use when submitting a SIP or SIPS SUBSCRIBE request for dereference purposes. If it is not defined in this specification, where is it defined? 2. Concerning PRES-URIs, we have the following text in 4.6: "If a location URI is included in a SIP request, it MUST be a SIP-, SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if the resulting resolution resolves to a SIP: or SIPS: URI, this section applies." The words "this section applies" are rather strange, because there is little else in this section. Maybe in a previous iteration there was more information here (on how to use a SIP/SIPS URI for dereference purposes). As things stand, the absence of information on how to resolve a SIP- or SIPS-URI applies also to PRES-URIs. 3. Also there is nothing to say what to do if the PRES URI fails to resolve to a SIP or SIPS URI. 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited above seems to preclude the addition of future URI schemes, which seems to be in conflict with 8.6 (registry establishment for location URIs). John _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Fri Aug 13 01:19:00 2010 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 472633A692C for ; Fri, 13 Aug 2010 01:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.761 X-Spam-Level: X-Spam-Status: No, score=-102.761 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, 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 ZxOmfvk-9KJ4 for ; Fri, 13 Aug 2010 01:18:59 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E286C3A6849 for ; Fri, 13 Aug 2010 01:18:58 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1160021; Fri, 13 Aug 2010 10:19:34 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 9DFCA1EB82AB; Fri, 13 Aug 2010 10:19:34 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 13 Aug 2010 10:19:34 +0200 From: "Elwell, John" To: "Winterbottom, James" , "sipcore@ietf.org" Date: Fri, 13 Aug 2010 10:19:32 +0200 Thread-Topic: Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYA= Message-ID: References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.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 Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 08:19:00 -0000 James, Thanks. True, this could be used, but the point is, if I receive a SIP/SIPS= -URI in a SIP Geolocation header field, how do I know what to use (e.g., RF= C 3856, RFC 3856 + RFC 4661, RFC 3856 + RFC 4661 + loc-filters, some other = event package). Unless something is specified in location-conveyance, how d= o I, as location recipient, know which event package and extensions are lik= ely to work at the referenced resource? John > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 > Sent: 12 August 2010 09:27 > To: Elwell, John; sipcore@ietf.org > Subject: RE: Questions on location conveyance and dereferencing >=20 > Hi John, >=20 > I think you could use this as a basic location subscription: > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 >=20 > There is already a lot of protest against point 2, and I=20 > believe that this is going to be fixed. >=20 > Cheers > James >=20 > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On=20 > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > Sent: Thursday, August 12, 2010 3:21 AM > To: sipcore@ietf.org > Subject: [sipcore] Questions on location conveyance and dereferencing >=20 > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES,=20 > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there=20 > seems to be an absence of specification of what event package=20 > to use when submitting a SIP or SIPS SUBSCRIBE request for=20 > dereference purposes. If it is not defined in this=20 > specification, where is it defined? >=20 > 2. Concerning PRES-URIs, we have the following text in 4.6: > "If a location URI is included in a SIP request, it MUST be a SIP-, > SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if > the resulting resolution resolves to a SIP: or SIPS: URI, this > section applies." >=20 > The words "this section applies" are rather strange, because=20 > there is little else in this section. Maybe in a previous=20 > iteration there was more information here (on how to use a=20 > SIP/SIPS URI for dereference purposes). As things stand, the=20 > absence of information on how to resolve a SIP- or SIPS-URI=20 > applies also to PRES-URIs. >=20 > 3. Also there is nothing to say what to do if the PRES URI=20 > fails to resolve to a SIP or SIPS URI. >=20 > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited=20 > above seems to preclude the addition of future URI schemes,=20 > which seems to be in conflict with 8.6 (registry=20 > establishment for location URIs). >=20 >=20 > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From James.Winterbottom@andrew.com Fri Aug 13 01:25:38 2010 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 DA6273A6965 for ; Fri, 13 Aug 2010 01:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=-0.770, 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 spx3hKVFl6De for ; Fri, 13 Aug 2010 01:25:37 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id A17223A695E for ; Fri, 13 Aug 2010 01:25:37 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:15323 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S30240947Ab0HMI0O convert rfc822-to-8bit (ORCPT ); Fri, 13 Aug 2010 03:26:14 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 13 Aug 2010 03:26:14 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 13 Aug 2010 16:26:11 +0800 From: "Winterbottom, James" To: "Elwell, John" , "sipcore@ietf.org" Date: Fri, 13 Aug 2010 16:24:17 +0800 Thread-Topic: Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629w== Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.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: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 08:25:39 -0000 Hi John, Those are valid points. For the most part I have really only been thinking about using HTTP URIs for HELD dereferencing in this header, so I haven't given a whole lot of thought to SIP outside of loc-filters. Do you have a recommendation? Cheers James ________________________________________ From: Elwell, John [john.elwell@siemens-enterprise.com] Sent: Friday, August 13, 2010 3:19 AM To: Winterbottom, James; sipcore@ietf.org Subject: RE: Questions on location conveyance and dereferencing James, Thanks. True, this could be used, but the point is, if I receive a SIP/SIPS-URI in a SIP Geolocation header field, how do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661, RFC 3856 + RFC 4661 + loc-filters, some other event package). Unless something is specified in location-conveyance, how do I, as location recipient, know which event package and extensions are likely to work at the referenced resource? John > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: 12 August 2010 09:27 > To: Elwell, John; sipcore@ietf.org > Subject: RE: Questions on location conveyance and dereferencing > > Hi John, > > I think you could use this as a basic location subscription: > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 > > There is already a lot of protest against point 2, and I > believe that this is going to be fixed. > > Cheers > James > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > Sent: Thursday, August 12, 2010 3:21 AM > To: sipcore@ietf.org > Subject: [sipcore] Questions on location conveyance and dereferencing > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there > seems to be an absence of specification of what event package > to use when submitting a SIP or SIPS SUBSCRIBE request for > dereference purposes. If it is not defined in this > specification, where is it defined? > > 2. Concerning PRES-URIs, we have the following text in 4.6: > "If a location URI is included in a SIP request, it MUST be a SIP-, > SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if > the resulting resolution resolves to a SIP: or SIPS: URI, this > section applies." > > The words "this section applies" are rather strange, because > there is little else in this section. Maybe in a previous > iteration there was more information here (on how to use a > SIP/SIPS URI for dereference purposes). As things stand, the > absence of information on how to resolve a SIP- or SIPS-URI > applies also to PRES-URIs. > > 3. Also there is nothing to say what to do if the PRES URI > fails to resolve to a SIP or SIPS URI. > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited > above seems to preclude the addition of future URI schemes, > which seems to be in conflict with 8.6 (registry > establishment for location URIs). > > > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From john.elwell@siemens-enterprise.com Fri Aug 13 01:34:48 2010 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 9AD583A6893 for ; Fri, 13 Aug 2010 01:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.759 X-Spam-Level: X-Spam-Status: No, score=-102.759 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, 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 ZQJGVnlh5nQ1 for ; Fri, 13 Aug 2010 01:34:47 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 841023A68C8 for ; Fri, 13 Aug 2010 01:34:41 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1160055; Fri, 13 Aug 2010 10:35:17 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id B7C111EB82AB; Fri, 13 Aug 2010 10:35:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 13 Aug 2010 10:35:17 +0200 From: "Elwell, John" To: "Winterbottom, James" , "sipcore@ietf.org" Date: Fri, 13 Aug 2010 10:35:15 +0200 Thread-Topic: Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAQxtw Message-ID: References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.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 Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 08:34:48 -0000 It seems to me we should mandate that RFC 3856 be used. I don't have an opi= nion as to what, if anything, we should say about RFC 4661, loc-filters, et= c.. John > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 > Sent: 13 August 2010 09:24 > To: Elwell, John; sipcore@ietf.org > Subject: RE: Questions on location conveyance and dereferencing >=20 > Hi John, >=20 > Those are valid points. For the most part I have really only=20 > been thinking about using HTTP URIs for HELD dereferencing in=20 > this header, so I haven't given a whole lot of thought to SIP=20 > outside of loc-filters. >=20 > Do you have a recommendation? >=20 > Cheers > James >=20 > ________________________________________ > From: Elwell, John [john.elwell@siemens-enterprise.com] > Sent: Friday, August 13, 2010 3:19 AM > To: Winterbottom, James; sipcore@ietf.org > Subject: RE: Questions on location conveyance and dereferencing >=20 > James, >=20 > Thanks. True, this could be used, but the point is, if I=20 > receive a SIP/SIPS-URI in a SIP Geolocation header field, how=20 > do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661,=20 > RFC 3856 + RFC 4661 + loc-filters, some other event package).=20 > Unless something is specified in location-conveyance, how do=20 > I, as location recipient, know which event package and=20 > extensions are likely to work at the referenced resource? >=20 > John >=20 >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: 12 August 2010 09:27 > > To: Elwell, John; sipcore@ietf.org > > Subject: RE: Questions on location conveyance and dereferencing > > > > Hi John, > > > > I think you could use this as a basic location subscription: > > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 > > > > There is already a lot of protest against point 2, and I > > believe that this is going to be fixed. > > > > Cheers > > James > > > > ________________________________________ > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > > Sent: Thursday, August 12, 2010 3:21 AM > > To: sipcore@ietf.org > > Subject: [sipcore] Questions on location conveyance and=20 > dereferencing > > > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, > > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there > > seems to be an absence of specification of what event package > > to use when submitting a SIP or SIPS SUBSCRIBE request for > > dereference purposes. If it is not defined in this > > specification, where is it defined? > > > > 2. Concerning PRES-URIs, we have the following text in 4.6: > > "If a location URI is included in a SIP request, it MUST be a SIP-, > > SIPS- or PRES-URI. When PRES: is used, as defined in=20 > [RFC3856], if > > the resulting resolution resolves to a SIP: or SIPS: URI, this > > section applies." > > > > The words "this section applies" are rather strange, because > > there is little else in this section. Maybe in a previous > > iteration there was more information here (on how to use a > > SIP/SIPS URI for dereference purposes). As things stand, the > > absence of information on how to resolve a SIP- or SIPS-URI > > applies also to PRES-URIs. > > > > 3. Also there is nothing to say what to do if the PRES URI > > fails to resolve to a SIP or SIPS URI. > > > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited > > above seems to preclude the addition of future URI schemes, > > which seems to be in conflict with 8.6 (registry > > establishment for location URIs). > > > > > > John > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > = From hannes.tschofenig@nsn.com Fri Aug 13 01:36:48 2010 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 0B46C3A6965 for ; Fri, 13 Aug 2010 01:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, 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 R3Ksd9xRzCkZ for ; Fri, 13 Aug 2010 01:36:46 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id C35643A68C8 for ; Fri, 13 Aug 2010 01:36:45 -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 o7D8bJRs022663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Aug 2010 10:37:19 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7D8bIHm000775; Fri, 13 Aug 2010 10:37:19 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Aug 2010 10:37: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: Fri, 13 Aug 2010 11:37:15 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQ References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Winterbottom, James" , "Elwell, John" , X-OriginalArrivalTime: 13 Aug 2010 08:37:16.0609 (UTC) FILETIME=[BC38B310:01CB3AC2] Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 08:36:48 -0000 Good questions, John!=20 I don't know why we need SIP/SIPS and the PRES URI scheme. Wouldn't SIP/SIPS already be sufficient?=20 If you only use RFC 3856 then you have no way to filter location; you might end up getting a lot of notifications. Still, it works.=20 If you use RFC 3856 with the location filters then you can additionally limit the number of notifications you get. The location filters works reuses RFC 4661 to a certain extend but my intention was that you do not need to implement the full RFC 4661 for location filtering because you do not need it nor does it seem to be useful either. Using RFC 4661 on the other hand would not get you too far in the area of location filtering.=20 So, the options are:=20 A) RFC 3856 B) RFC 3856 + loc-filters.=20 If you send a SUBSCRIBE with loc-filters and the other party does not understand it then the error handling in RFC 3856 should kick in. =20 Does this make sense to you?=20 Ciao Hannes PS: With the work on loc-filters I suggested to get rid of RFC 4661 completely and to build loc-filters on top of something entirely different (for example a scripting language like JavaScript) but the group did not like it.=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Winterbottom, James > Sent: Friday, August 13, 2010 11:24 AM > To: Elwell, John; sipcore@ietf.org > Subject: Re: [sipcore] Questions on location conveyance and=20 > dereferencing >=20 > Hi John, >=20 > Those are valid points. For the most part I have really only=20 > been thinking about using HTTP URIs for HELD dereferencing in=20 > this header, so I haven't given a whole lot of thought to SIP=20 > outside of loc-filters. >=20 > Do you have a recommendation? >=20 > Cheers > James >=20 > ________________________________________ > From: Elwell, John [john.elwell@siemens-enterprise.com] > Sent: Friday, August 13, 2010 3:19 AM > To: Winterbottom, James; sipcore@ietf.org > Subject: RE: Questions on location conveyance and dereferencing >=20 > James, >=20 > Thanks. True, this could be used, but the point is, if I=20 > receive a SIP/SIPS-URI in a SIP Geolocation header field, how=20 > do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661,=20 > RFC 3856 + RFC 4661 + loc-filters, some other event package).=20 > Unless something is specified in location-conveyance, how do=20 > I, as location recipient, know which event package and=20 > extensions are likely to work at the referenced resource? >=20 > John >=20 >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: 12 August 2010 09:27 > > To: Elwell, John; sipcore@ietf.org > > Subject: RE: Questions on location conveyance and dereferencing > > > > Hi John, > > > > I think you could use this as a basic location subscription: > > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 > > > > There is already a lot of protest against point 2, and I > > believe that this is going to be fixed. > > > > Cheers > > James > > > > ________________________________________ > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > > Sent: Thursday, August 12, 2010 3:21 AM > > To: sipcore@ietf.org > > Subject: [sipcore] Questions on location conveyance and=20 > dereferencing > > > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, > > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there > > seems to be an absence of specification of what event package > > to use when submitting a SIP or SIPS SUBSCRIBE request for > > dereference purposes. If it is not defined in this > > specification, where is it defined? > > > > 2. Concerning PRES-URIs, we have the following text in 4.6: > > "If a location URI is included in a SIP request, it MUST be a SIP-, > > SIPS- or PRES-URI. When PRES: is used, as defined in=20 > [RFC3856], if > > the resulting resolution resolves to a SIP: or SIPS: URI, this > > section applies." > > > > The words "this section applies" are rather strange, because > > there is little else in this section. Maybe in a previous > > iteration there was more information here (on how to use a > > SIP/SIPS URI for dereference purposes). As things stand, the > > absence of information on how to resolve a SIP- or SIPS-URI > > applies also to PRES-URIs. > > > > 3. Also there is nothing to say what to do if the PRES URI > > fails to resolve to a SIP or SIPS URI. > > > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited > > above seems to preclude the addition of future URI schemes, > > which seems to be in conflict with 8.6 (registry > > establishment for location URIs). > > > > > > John > > _______________________________________________ > > 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 >=20 From James.Winterbottom@andrew.com Fri Aug 13 01:39:27 2010 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 447053A69B4 for ; Fri, 13 Aug 2010 01:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.700, 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 fkobeHEkKIxD for ; Fri, 13 Aug 2010 01:39:26 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id DCA4A3A69A3 for ; Fri, 13 Aug 2010 01:39:25 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:44454 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S360359Ab0HMIkC (ORCPT ); Fri, 13 Aug 2010 03:40:02 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 13 Aug 2010 03:40:02 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 13 Aug 2010 16:39:58 +0800 From: "Winterbottom, James" To: "'hannes.tschofenig@nsn.com'" , "'john.elwell@siemens-enterprise.com'" , "'sipcore@ietf.org'" Date: Fri, 13 Aug 2010 16:39:56 +0800 Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAABwLYs= Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120EB868F5C@SISPE7MB1.commscope.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 08:39:27 -0000 SSB0aGluayB0aGlzIG1ha2VzIHNlbnNlIEhhbm5lcy4NCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCkZyb206IFRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pIDxo YW5uZXMudHNjaG9mZW5pZ0Buc24uY29tPg0KVG86IFdpbnRlcmJvdHRvbSwgSmFtZXM7IEVsd2Vs bCwgSm9obiA8am9obi5lbHdlbGxAc2llbWVucy1lbnRlcnByaXNlLmNvbT47IHNpcGNvcmVAaWV0 Zi5vcmcgPHNpcGNvcmVAaWV0Zi5vcmc+DQpTZW50OiBGcmkgQXVnIDEzIDE2OjM3OjE1IDIwMTAK U3ViamVjdDogUkU6IFtzaXBjb3JlXSBRdWVzdGlvbnMgb24gbG9jYXRpb24gY29udmV5YW5jZSBh bmQgZGVyZWZlcmVuY2luZw0KDQpHb29kIHF1ZXN0aW9ucywgSm9obiEgDQoNCkkgZG9uJ3Qga25v dyB3aHkgd2UgbmVlZCBTSVAvU0lQUyBhbmQgdGhlIFBSRVMgVVJJIHNjaGVtZS4gV291bGRuJ3QN ClNJUC9TSVBTIGFscmVhZHkgYmUgc3VmZmljaWVudD8gDQoNCklmIHlvdSBvbmx5IHVzZSBSRkMg Mzg1NiB0aGVuIHlvdSBoYXZlIG5vIHdheSB0byBmaWx0ZXIgbG9jYXRpb247IHlvdQ0KbWlnaHQg ZW5kIHVwIGdldHRpbmcgYSBsb3Qgb2Ygbm90aWZpY2F0aW9ucy4gU3RpbGwsIGl0IHdvcmtzLiAN Cg0KSWYgeW91IHVzZSBSRkMgMzg1NiB3aXRoIHRoZSBsb2NhdGlvbiBmaWx0ZXJzIHRoZW4geW91 IGNhbiBhZGRpdGlvbmFsbHkNCmxpbWl0IHRoZSBudW1iZXIgb2Ygbm90aWZpY2F0aW9ucyB5b3Ug Z2V0LiBUaGUgbG9jYXRpb24gZmlsdGVycyB3b3Jrcw0KcmV1c2VzIFJGQyA0NjYxIHRvIGEgY2Vy dGFpbiBleHRlbmQgYnV0IG15IGludGVudGlvbiB3YXMgdGhhdCB5b3UgZG8gbm90DQpuZWVkIHRv IGltcGxlbWVudCB0aGUgZnVsbCBSRkMgNDY2MSBmb3IgbG9jYXRpb24gZmlsdGVyaW5nIGJlY2F1 c2UgeW91DQpkbyBub3QgbmVlZCBpdCAgbm9yIGRvZXMgaXQgc2VlbSB0byBiZSB1c2VmdWwgZWl0 aGVyLiBVc2luZyBSRkMgNDY2MSBvbg0KdGhlIG90aGVyIGhhbmQgd291bGQgbm90IGdldCB5b3Ug dG9vIGZhciBpbiB0aGUgYXJlYSBvZiBsb2NhdGlvbg0KZmlsdGVyaW5nLiANCg0KU28sIHRoZSBv cHRpb25zIGFyZTogDQoNCkEpIFJGQyAzODU2DQpCKSBSRkMgMzg1NiArIGxvYy1maWx0ZXJzLiAN Cg0KSWYgeW91IHNlbmQgYSBTVUJTQ1JJQkUgd2l0aCBsb2MtZmlsdGVycyBhbmQgdGhlIG90aGVy IHBhcnR5IGRvZXMgbm90DQp1bmRlcnN0YW5kIGl0IHRoZW4gdGhlIGVycm9yIGhhbmRsaW5nIGlu IFJGQyAzODU2IHNob3VsZCBraWNrIGluLiAgDQoNCkRvZXMgdGhpcyBtYWtlIHNlbnNlIHRvIHlv dT8gDQoNCkNpYW8NCkhhbm5lcw0KDQpQUzogV2l0aCB0aGUgd29yayBvbiBsb2MtZmlsdGVycyBJ IHN1Z2dlc3RlZCB0byBnZXQgcmlkIG9mIFJGQyA0NjYxDQpjb21wbGV0ZWx5IGFuZCB0byBidWls ZCBsb2MtZmlsdGVycyBvbiB0b3Agb2Ygc29tZXRoaW5nIGVudGlyZWx5DQpkaWZmZXJlbnQgKGZv ciBleGFtcGxlIGEgc2NyaXB0aW5nIGxhbmd1YWdlIGxpa2UgSmF2YVNjcmlwdCkgYnV0IHRoZQ0K Z3JvdXAgZGlkIG5vdCBsaWtlIGl0LiANCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyANCj4gW21haWx0bzpzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgV2ludGVyYm90dG9tLCBKYW1lcw0KPiBT ZW50OiBGcmlkYXksIEF1Z3VzdCAxMywgMjAxMCAxMToyNCBBTQ0KPiBUbzogRWx3ZWxsLCBKb2hu OyBzaXBjb3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2lwY29yZV0gUXVlc3Rpb25zIG9u IGxvY2F0aW9uIGNvbnZleWFuY2UgYW5kIA0KPiBkZXJlZmVyZW5jaW5nDQo+IA0KPiBIaSBKb2hu LA0KPiANCj4gVGhvc2UgYXJlIHZhbGlkIHBvaW50cy4gRm9yIHRoZSBtb3N0IHBhcnQgSSBoYXZl IHJlYWxseSBvbmx5IA0KPiBiZWVuIHRoaW5raW5nIGFib3V0IHVzaW5nIEhUVFAgVVJJcyBmb3Ig SEVMRCBkZXJlZmVyZW5jaW5nIGluIA0KPiB0aGlzIGhlYWRlciwgc28gSSBoYXZlbid0IGdpdmVu IGEgd2hvbGUgbG90IG9mIHRob3VnaHQgdG8gU0lQIA0KPiBvdXRzaWRlIG9mIGxvYy1maWx0ZXJz Lg0KPiANCj4gRG8geW91IGhhdmUgYSByZWNvbW1lbmRhdGlvbj8NCj4gDQo+IENoZWVycw0KPiBK YW1lcw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBG cm9tOiBFbHdlbGwsIEpvaG4gW2pvaG4uZWx3ZWxsQHNpZW1lbnMtZW50ZXJwcmlzZS5jb21dDQo+ IFNlbnQ6IEZyaWRheSwgQXVndXN0IDEzLCAyMDEwIDM6MTkgQU0NCj4gVG86IFdpbnRlcmJvdHRv bSwgSmFtZXM7IHNpcGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFF1ZXN0aW9ucyBvbiBs b2NhdGlvbiBjb252ZXlhbmNlIGFuZCBkZXJlZmVyZW5jaW5nDQo+IA0KPiBKYW1lcywNCj4gDQo+ IFRoYW5rcy4gVHJ1ZSwgdGhpcyBjb3VsZCBiZSB1c2VkLCBidXQgdGhlIHBvaW50IGlzLCBpZiBJ IA0KPiByZWNlaXZlIGEgU0lQL1NJUFMtVVJJIGluIGEgU0lQIEdlb2xvY2F0aW9uIGhlYWRlciBm aWVsZCwgaG93IA0KPiBkbyBJIGtub3cgd2hhdCB0byB1c2UgKGUuZy4sIFJGQyAzODU2LCBSRkMg Mzg1NiArIFJGQyA0NjYxLCANCj4gUkZDIDM4NTYgKyBSRkMgNDY2MSArIGxvYy1maWx0ZXJzLCBz b21lIG90aGVyIGV2ZW50IHBhY2thZ2UpLiANCj4gVW5sZXNzIHNvbWV0aGluZyBpcyBzcGVjaWZp ZWQgaW4gbG9jYXRpb24tY29udmV5YW5jZSwgaG93IGRvIA0KPiBJLCBhcyBsb2NhdGlvbiByZWNp cGllbnQsIGtub3cgd2hpY2ggZXZlbnQgcGFja2FnZSBhbmQgDQo+IGV4dGVuc2lvbnMgYXJlIGxp a2VseSB0byB3b3JrIGF0IHRoZSByZWZlcmVuY2VkIHJlc291cmNlPw0KPiANCj4gSm9obg0KPiAN Cj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBXaW50ZXJib3R0 b20sIEphbWVzIFttYWlsdG86SmFtZXMuV2ludGVyYm90dG9tQGFuZHJldy5jb21dDQo+ID4gU2Vu dDogMTIgQXVndXN0IDIwMTAgMDk6MjcNCj4gPiBUbzogRWx3ZWxsLCBKb2huOyBzaXBjb3JlQGll dGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFF1ZXN0aW9ucyBvbiBsb2NhdGlvbiBjb252ZXlhbmNl IGFuZCBkZXJlZmVyZW5jaW5nDQo+ID4NCj4gPiBIaSBKb2huLA0KPiA+DQo+ID4gSSB0aGluayB5 b3UgY291bGQgdXNlIHRoaXMgYXMgYSBiYXNpYyBsb2NhdGlvbiBzdWJzY3JpcHRpb246DQo+ID4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1nZW9wcml2LWxvYy1maWx0ZXJz LTExDQo+ID4NCj4gPiBUaGVyZSBpcyBhbHJlYWR5IGEgbG90IG9mIHByb3Rlc3QgYWdhaW5zdCBw b2ludCAyLCBhbmQgSQ0KPiA+IGJlbGlldmUgdGhhdCB0aGlzIGlzIGdvaW5nIHRvIGJlIGZpeGVk Lg0KPiA+DQo+ID4gQ2hlZXJzDQo+ID4gSmFtZXMNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmcgW3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiBCZWhhbGYgT2YgRWx3ZWxsLCBK b2huIFtqb2huLmVsd2VsbEBzaWVtZW5zLWVudGVycHJpc2UuY29tXQ0KPiA+IFNlbnQ6IFRodXJz ZGF5LCBBdWd1c3QgMTIsIDIwMTAgMzoyMSBBTQ0KPiA+IFRvOiBzaXBjb3JlQGlldGYub3JnDQo+ ID4gU3ViamVjdDogW3NpcGNvcmVdIFF1ZXN0aW9ucyBvbiBsb2NhdGlvbiBjb252ZXlhbmNlIGFu ZCANCj4gZGVyZWZlcmVuY2luZw0KPiA+DQo+ID4gMS4gRHJhZnQtaWV0Zi1zaXBjb3JlLWxvY2F0 aW9uLWNvbnZleWFuY2UtMDMgZGVmaW5lcyBQUkVTLA0KPiA+IFNJUCBhbmQgU0lQUyBVUkkgc2No ZW1lcyBmb3IgTGJ5Ui4gRm9yIFNJUCBhbmQgU0lQUywgdGhlcmUNCj4gPiBzZWVtcyB0byBiZSBh biBhYnNlbmNlIG9mIHNwZWNpZmljYXRpb24gb2Ygd2hhdCBldmVudCBwYWNrYWdlDQo+ID4gdG8g dXNlIHdoZW4gc3VibWl0dGluZyBhIFNJUCBvciBTSVBTIFNVQlNDUklCRSByZXF1ZXN0IGZvcg0K PiA+IGRlcmVmZXJlbmNlIHB1cnBvc2VzLiBJZiBpdCBpcyBub3QgZGVmaW5lZCBpbiB0aGlzDQo+ ID4gc3BlY2lmaWNhdGlvbiwgd2hlcmUgaXMgaXQgZGVmaW5lZD8NCj4gPg0KPiA+IDIuIENvbmNl cm5pbmcgUFJFUy1VUklzLCB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiA0LjY6DQo+ID4g IklmIGEgbG9jYXRpb24gVVJJIGlzIGluY2x1ZGVkIGluIGEgU0lQIHJlcXVlc3QsIGl0IE1VU1Qg YmUgYSBTSVAtLA0KPiA+ICAgIFNJUFMtIG9yIFBSRVMtVVJJLiAgV2hlbiBQUkVTOiBpcyB1c2Vk LCBhcyBkZWZpbmVkIGluIA0KPiBbUkZDMzg1Nl0sIGlmDQo+ID4gICAgdGhlIHJlc3VsdGluZyBy ZXNvbHV0aW9uIHJlc29sdmVzIHRvIGEgU0lQOiBvciBTSVBTOiBVUkksIHRoaXMNCj4gPiAgICBz ZWN0aW9uIGFwcGxpZXMuIg0KPiA+DQo+ID4gVGhlIHdvcmRzICJ0aGlzIHNlY3Rpb24gYXBwbGll cyIgYXJlIHJhdGhlciBzdHJhbmdlLCBiZWNhdXNlDQo+ID4gdGhlcmUgaXMgbGl0dGxlIGVsc2Ug aW4gdGhpcyBzZWN0aW9uLiBNYXliZSBpbiBhIHByZXZpb3VzDQo+ID4gaXRlcmF0aW9uIHRoZXJl IHdhcyBtb3JlIGluZm9ybWF0aW9uIGhlcmUgKG9uIGhvdyB0byB1c2UgYQ0KPiA+IFNJUC9TSVBT IFVSSSBmb3IgZGVyZWZlcmVuY2UgcHVycG9zZXMpLiBBcyB0aGluZ3Mgc3RhbmQsIHRoZQ0KPiA+ IGFic2VuY2Ugb2YgaW5mb3JtYXRpb24gb24gaG93IHRvIHJlc29sdmUgYSBTSVAtIG9yIFNJUFMt VVJJDQo+ID4gYXBwbGllcyBhbHNvIHRvIFBSRVMtVVJJcy4NCj4gPg0KPiA+IDMuIEFsc28gdGhl cmUgaXMgbm90aGluZyB0byBzYXkgd2hhdCB0byBkbyBpZiB0aGUgUFJFUyBVUkkNCj4gPiBmYWls cyB0byByZXNvbHZlIHRvIGEgU0lQIG9yIFNJUFMgVVJJLg0KPiA+DQo+ID4gNC4gVGhlICJNVVNU IGJlIGEgU0lQLSwgU0lQUy0gb3IgUFJFUy1VUkkiIHRleHQgaW4gY2l0ZWQNCj4gPiBhYm92ZSBz ZWVtcyB0byBwcmVjbHVkZSB0aGUgYWRkaXRpb24gb2YgZnV0dXJlIFVSSSBzY2hlbWVzLA0KPiA+ IHdoaWNoIHNlZW1zIHRvIGJlIGluIGNvbmZsaWN0IHdpdGggOC42IChyZWdpc3RyeQ0KPiA+IGVz dGFibGlzaG1lbnQgZm9yIGxvY2F0aW9uIFVSSXMpLg0KPiA+DQo+ID4NCj4gPiBKb2huDQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzaXBj b3JlIG1haWxpbmcgbGlzdA0KPiA+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0K PiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZQ0KPiANCg== From john.elwell@siemens-enterprise.com Fri Aug 13 02:03:49 2010 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 7C7A63A6784 for ; Fri, 13 Aug 2010 02:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.756 X-Spam-Level: X-Spam-Status: No, score=-102.756 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, 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 cO0qExf7hVdY for ; Fri, 13 Aug 2010 02:03:46 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3299D3A6934 for ; Fri, 13 Aug 2010 02:03:45 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1161750; Fri, 13 Aug 2010 11:04:22 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 0A89023F028E; Fri, 13 Aug 2010 11:04:22 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 13 Aug 2010 11:04:22 +0200 From: "Elwell, John" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Winterbottom, James" , "sipcore@ietf.org" Date: Fri, 13 Aug 2010 11:04:20 +0200 Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJA= Message-ID: References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net> 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 Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 09:03:49 -0000 In fact, proliferation of URI schemes is a problem. If we have n URI scheme= s standardized for inclusion in the Geolocation header field, then a recipi= ent would need to support dereferencing for all n schemes. There is no nego= tiation mechanism whereby the inserter can select a scheme that the recipie= nt is known to support. Sounds like an interop nightmare. Perhaps we should= go as far as limiting it to a single scheme: HTTPS (using HELD with identi= ty-extensions)? This would just get you the location, without the rest of p= resence. Or perhaps we should allow in the Geolocation header field several= URIs with different schemes, any of which can reach the same location reso= urce. John > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo)=20 > [mailto:hannes.tschofenig@nsn.com]=20 > Sent: 13 August 2010 09:37 > To: ext Winterbottom, James; Elwell, John; sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and=20 > dereferencing >=20 > Good questions, John!=20 >=20 > I don't know why we need SIP/SIPS and the PRES URI scheme. Wouldn't > SIP/SIPS already be sufficient?=20 >=20 > If you only use RFC 3856 then you have no way to filter location; you > might end up getting a lot of notifications. Still, it works.=20 >=20 > If you use RFC 3856 with the location filters then you can=20 > additionally > limit the number of notifications you get. The location filters works > reuses RFC 4661 to a certain extend but my intention was that=20 > you do not > need to implement the full RFC 4661 for location filtering because you > do not need it nor does it seem to be useful either. Using=20 > RFC 4661 on > the other hand would not get you too far in the area of location > filtering.=20 >=20 > So, the options are:=20 >=20 > A) RFC 3856 > B) RFC 3856 + loc-filters.=20 >=20 > If you send a SUBSCRIBE with loc-filters and the other party does not > understand it then the error handling in RFC 3856 should kick in. =20 >=20 > Does this make sense to you?=20 >=20 > Ciao > Hannes >=20 > PS: With the work on loc-filters I suggested to get rid of RFC 4661 > completely and to build loc-filters on top of something entirely > different (for example a scripting language like JavaScript) but the > group did not like it.=20 >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org=20 > > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext=20 > Winterbottom, James > > Sent: Friday, August 13, 2010 11:24 AM > > To: Elwell, John; sipcore@ietf.org > > Subject: Re: [sipcore] Questions on location conveyance and=20 > > dereferencing > >=20 > > Hi John, > >=20 > > Those are valid points. For the most part I have really only=20 > > been thinking about using HTTP URIs for HELD dereferencing in=20 > > this header, so I haven't given a whole lot of thought to SIP=20 > > outside of loc-filters. > >=20 > > Do you have a recommendation? > >=20 > > Cheers > > James > >=20 > > ________________________________________ > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > Sent: Friday, August 13, 2010 3:19 AM > > To: Winterbottom, James; sipcore@ietf.org > > Subject: RE: Questions on location conveyance and dereferencing > >=20 > > James, > >=20 > > Thanks. True, this could be used, but the point is, if I=20 > > receive a SIP/SIPS-URI in a SIP Geolocation header field, how=20 > > do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661,=20 > > RFC 3856 + RFC 4661 + loc-filters, some other event package).=20 > > Unless something is specified in location-conveyance, how do=20 > > I, as location recipient, know which event package and=20 > > extensions are likely to work at the referenced resource? > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: 12 August 2010 09:27 > > > To: Elwell, John; sipcore@ietf.org > > > Subject: RE: Questions on location conveyance and dereferencing > > > > > > Hi John, > > > > > > I think you could use this as a basic location subscription: > > > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 > > > > > > There is already a lot of protest against point 2, and I > > > believe that this is going to be fixed. > > > > > > Cheers > > > James > > > > > > ________________________________________ > > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > > > Sent: Thursday, August 12, 2010 3:21 AM > > > To: sipcore@ietf.org > > > Subject: [sipcore] Questions on location conveyance and=20 > > dereferencing > > > > > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, > > > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there > > > seems to be an absence of specification of what event package > > > to use when submitting a SIP or SIPS SUBSCRIBE request for > > > dereference purposes. If it is not defined in this > > > specification, where is it defined? > > > > > > 2. Concerning PRES-URIs, we have the following text in 4.6: > > > "If a location URI is included in a SIP request, it MUST=20 > be a SIP-, > > > SIPS- or PRES-URI. When PRES: is used, as defined in=20 > > [RFC3856], if > > > the resulting resolution resolves to a SIP: or SIPS: URI, this > > > section applies." > > > > > > The words "this section applies" are rather strange, because > > > there is little else in this section. Maybe in a previous > > > iteration there was more information here (on how to use a > > > SIP/SIPS URI for dereference purposes). As things stand, the > > > absence of information on how to resolve a SIP- or SIPS-URI > > > applies also to PRES-URIs. > > > > > > 3. Also there is nothing to say what to do if the PRES URI > > > fails to resolve to a SIP or SIPS URI. > > > > > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited > > > above seems to preclude the addition of future URI schemes, > > > which seems to be in conflict with 8.6 (registry > > > establishment for location URIs). > > > > > > > > > John > > > _______________________________________________ > > > 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 > >=20 > = From James.Winterbottom@andrew.com Fri Aug 13 02:13:52 2010 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 167123A68D7 for ; Fri, 13 Aug 2010 02:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=-0.642, 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 o+B-ccWUkVLE for ; Fri, 13 Aug 2010 02:13:48 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 108513A68DA for ; Fri, 13 Aug 2010 02:13:48 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:33204 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S217523Ab0HMJOY convert rfc822-to-8bit (ORCPT ); Fri, 13 Aug 2010 04:14:24 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 13 Aug 2010 04:14:24 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 13 Aug 2010 17:14:19 +0800 From: "Winterbottom, James" To: "Elwell, John" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "sipcore@ietf.org" Date: Fri, 13 Aug 2010 17:14:19 +0800 Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYw== Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, 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: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 09:13:52 -0000 Hi John, I am inclined to agree that proliferation of URI schemes may be a problem. I am also inclined to think that there really aren't that many common URI schemes with multiple interpretation with regard to how you get location information from them. I could be wrong here though. As far as the HELD side of things go, I was really thinking that you would get a URI from the LIS that uniquely identifies the Target/resource, as is described in the dereference draft. Previous revisions of the conveyance draft have allowed multiple header instances and it would have been possible to include additional URI schemes by adding abother header. I don't really want to go back to this scheme. If you are proposing that a single header may include multiple URI types, this might work, but I would oppose forcing these to be directly specified in the ABNF since this would limit extensibility unnecessarily. Cheers James ________________________________________ From: Elwell, John [john.elwell@siemens-enterprise.com] Sent: Friday, August 13, 2010 4:04 AM To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; sipcore@ietf.org Subject: RE: [sipcore] Questions on location conveyance and dereferencing In fact, proliferation of URI schemes is a problem. If we have n URI schemes standardized for inclusion in the Geolocation header field, then a recipient would need to support dereferencing for all n schemes. There is no negotiation mechanism whereby the inserter can select a scheme that the recipient is known to support. Sounds like an interop nightmare. Perhaps we should go as far as limiting it to a single scheme: HTTPS (using HELD with identity-extensions)? This would just get you the location, without the rest of presence. Or perhaps we should allow in the Geolocation header field several URIs with different schemes, any of which can reach the same location resource. John > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: 13 August 2010 09:37 > To: ext Winterbottom, James; Elwell, John; sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and > dereferencing > > Good questions, John! > > I don't know why we need SIP/SIPS and the PRES URI scheme. Wouldn't > SIP/SIPS already be sufficient? > > If you only use RFC 3856 then you have no way to filter location; you > might end up getting a lot of notifications. Still, it works. > > If you use RFC 3856 with the location filters then you can > additionally > limit the number of notifications you get. The location filters works > reuses RFC 4661 to a certain extend but my intention was that > you do not > need to implement the full RFC 4661 for location filtering because you > do not need it nor does it seem to be useful either. Using > RFC 4661 on > the other hand would not get you too far in the area of location > filtering. > > So, the options are: > > A) RFC 3856 > B) RFC 3856 + loc-filters. > > If you send a SUBSCRIBE with loc-filters and the other party does not > understand it then the error handling in RFC 3856 should kick in. > > Does this make sense to you? > > Ciao > Hannes > > PS: With the work on loc-filters I suggested to get rid of RFC 4661 > completely and to build loc-filters on top of something entirely > different (for example a scripting language like JavaScript) but the > group did not like it. > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext > Winterbottom, James > > Sent: Friday, August 13, 2010 11:24 AM > > To: Elwell, John; sipcore@ietf.org > > Subject: Re: [sipcore] Questions on location conveyance and > > dereferencing > > > > Hi John, > > > > Those are valid points. For the most part I have really only > > been thinking about using HTTP URIs for HELD dereferencing in > > this header, so I haven't given a whole lot of thought to SIP > > outside of loc-filters. > > > > Do you have a recommendation? > > > > Cheers > > James > > > > ________________________________________ > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > Sent: Friday, August 13, 2010 3:19 AM > > To: Winterbottom, James; sipcore@ietf.org > > Subject: RE: Questions on location conveyance and dereferencing > > > > James, > > > > Thanks. True, this could be used, but the point is, if I > > receive a SIP/SIPS-URI in a SIP Geolocation header field, how > > do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661, > > RFC 3856 + RFC 4661 + loc-filters, some other event package). > > Unless something is specified in location-conveyance, how do > > I, as location recipient, know which event package and > > extensions are likely to work at the referenced resource? > > > > John > > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: 12 August 2010 09:27 > > > To: Elwell, John; sipcore@ietf.org > > > Subject: RE: Questions on location conveyance and dereferencing > > > > > > Hi John, > > > > > > I think you could use this as a basic location subscription: > > > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 > > > > > > There is already a lot of protest against point 2, and I > > > believe that this is going to be fixed. > > > > > > Cheers > > > James > > > > > > ________________________________________ > > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > > > Sent: Thursday, August 12, 2010 3:21 AM > > > To: sipcore@ietf.org > > > Subject: [sipcore] Questions on location conveyance and > > dereferencing > > > > > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, > > > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there > > > seems to be an absence of specification of what event package > > > to use when submitting a SIP or SIPS SUBSCRIBE request for > > > dereference purposes. If it is not defined in this > > > specification, where is it defined? > > > > > > 2. Concerning PRES-URIs, we have the following text in 4.6: > > > "If a location URI is included in a SIP request, it MUST > be a SIP-, > > > SIPS- or PRES-URI. When PRES: is used, as defined in > > [RFC3856], if > > > the resulting resolution resolves to a SIP: or SIPS: URI, this > > > section applies." > > > > > > The words "this section applies" are rather strange, because > > > there is little else in this section. Maybe in a previous > > > iteration there was more information here (on how to use a > > > SIP/SIPS URI for dereference purposes). As things stand, the > > > absence of information on how to resolve a SIP- or SIPS-URI > > > applies also to PRES-URIs. > > > > > > 3. Also there is nothing to say what to do if the PRES URI > > > fails to resolve to a SIP or SIPS URI. > > > > > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited > > > above seems to preclude the addition of future URI schemes, > > > which seems to be in conflict with 8.6 (registry > > > establishment for location URIs). > > > > > > > > > John > > > _______________________________________________ > > > 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 john.elwell@siemens-enterprise.com Fri Aug 13 02:25:11 2010 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 7902A3A690C for ; Fri, 13 Aug 2010 02:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.754 X-Spam-Level: X-Spam-Status: No, score=-102.754 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, 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 lcMrmIBIUuHx for ; Fri, 13 Aug 2010 02:25:10 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A6AA23A6784 for ; Fri, 13 Aug 2010 02:25:09 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1162029; Fri, 13 Aug 2010 11:25:45 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8C66F23F0292; Fri, 13 Aug 2010 11:25:45 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 13 Aug 2010 11:25:45 +0200 From: "Elwell, John" To: "Winterbottom, James" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "sipcore@ietf.org" Date: Fri, 13 Aug 2010 11:25:44 +0200 Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYwAAUJuA Message-ID: References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.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 Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 09:25:11 -0000 James, I am not really making a firm proposal, and I am indeed aware of the histor= y of location-conveyance and don't want to go back to the multiple location= s model that we had previously. However, for a single location, if there ar= e multiple URI schemes, I see the following possibilities: - limit the number of URI schemes and say the recipient MUST implement all = (the ultimate version of this is to have only a single URI scheme); - define a limited number (perhaps just one) of MUST implement URI schemes,= and allow the conveyance of multiple URIs with different schemes, all refe= rencing the same location resource, at least one of which is a MUST impleme= nt scheme; - have some sort of negotiation mechanism - but I don't want to go there be= cause of adding round-trips, particularly a problem for emergency calls. Any other possibilities? John > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 > Sent: 13 August 2010 10:14 > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo);=20 > sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and=20 > dereferencing >=20 > Hi John, >=20 > I am inclined to agree that proliferation of URI schemes may=20 > be a problem. I am also inclined to think that there really=20 > aren't that many common URI schemes with multiple=20 > interpretation with regard to how you get location=20 > information from them. I could be wrong here though. >=20 > As far as the HELD side of things go, I was really thinking=20 > that you would get a URI from the LIS that uniquely=20 > identifies the Target/resource, as is described in the=20 > dereference draft. >=20 > Previous revisions of the conveyance draft have allowed=20 > multiple header instances and it would have been possible to=20 > include additional URI schemes by adding abother header. I=20 > don't really want to go back to this scheme. If you are=20 > proposing that a single header may include multiple URI=20 > types, this might work, but I would oppose forcing these to=20 > be directly specified in the ABNF since this would limit=20 > extensibility unnecessarily. >=20 > Cheers > James > ________________________________________ > From: Elwell, John [john.elwell@siemens-enterprise.com] > Sent: Friday, August 13, 2010 4:04 AM > To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James;=20 > sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and=20 > dereferencing >=20 > In fact, proliferation of URI schemes is a problem. If we=20 > have n URI schemes standardized for inclusion in the=20 > Geolocation header field, then a recipient would need to=20 > support dereferencing for all n schemes. There is no=20 > negotiation mechanism whereby the inserter can select a=20 > scheme that the recipient is known to support. Sounds like an=20 > interop nightmare. Perhaps we should go as far as limiting it=20 > to a single scheme: HTTPS (using HELD with=20 > identity-extensions)? This would just get you the location,=20 > without the rest of presence. Or perhaps we should allow in=20 > the Geolocation header field several URIs with different=20 > schemes, any of which can reach the same location resource. >=20 > John >=20 > > -----Original Message----- > > From: Tschofenig, Hannes (NSN - FI/Espoo) > > [mailto:hannes.tschofenig@nsn.com] > > Sent: 13 August 2010 09:37 > > To: ext Winterbottom, James; Elwell, John; sipcore@ietf.org > > Subject: RE: [sipcore] Questions on location conveyance and > > dereferencing > > > > Good questions, John! > > > > I don't know why we need SIP/SIPS and the PRES URI scheme. Wouldn't > > SIP/SIPS already be sufficient? > > > > If you only use RFC 3856 then you have no way to filter=20 > location; you > > might end up getting a lot of notifications. Still, it works. > > > > If you use RFC 3856 with the location filters then you can > > additionally > > limit the number of notifications you get. The location=20 > filters works > > reuses RFC 4661 to a certain extend but my intention was that > > you do not > > need to implement the full RFC 4661 for location filtering=20 > because you > > do not need it nor does it seem to be useful either. Using > > RFC 4661 on > > the other hand would not get you too far in the area of location > > filtering. > > > > So, the options are: > > > > A) RFC 3856 > > B) RFC 3856 + loc-filters. > > > > If you send a SUBSCRIBE with loc-filters and the other=20 > party does not > > understand it then the error handling in RFC 3856 should kick in. > > > > Does this make sense to you? > > > > Ciao > > Hannes > > > > PS: With the work on loc-filters I suggested to get rid of RFC 4661 > > completely and to build loc-filters on top of something entirely > > different (for example a scripting language like JavaScript) but the > > group did not like it. > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext > > Winterbottom, James > > > Sent: Friday, August 13, 2010 11:24 AM > > > To: Elwell, John; sipcore@ietf.org > > > Subject: Re: [sipcore] Questions on location conveyance and > > > dereferencing > > > > > > Hi John, > > > > > > Those are valid points. For the most part I have really only > > > been thinking about using HTTP URIs for HELD dereferencing in > > > this header, so I haven't given a whole lot of thought to SIP > > > outside of loc-filters. > > > > > > Do you have a recommendation? > > > > > > Cheers > > > James > > > > > > ________________________________________ > > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > > Sent: Friday, August 13, 2010 3:19 AM > > > To: Winterbottom, James; sipcore@ietf.org > > > Subject: RE: Questions on location conveyance and dereferencing > > > > > > James, > > > > > > Thanks. True, this could be used, but the point is, if I > > > receive a SIP/SIPS-URI in a SIP Geolocation header field, how > > > do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661, > > > RFC 3856 + RFC 4661 + loc-filters, some other event package). > > > Unless something is specified in location-conveyance, how do > > > I, as location recipient, know which event package and > > > extensions are likely to work at the referenced resource? > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: 12 August 2010 09:27 > > > > To: Elwell, John; sipcore@ietf.org > > > > Subject: RE: Questions on location conveyance and dereferencing > > > > > > > > Hi John, > > > > > > > > I think you could use this as a basic location subscription: > > > > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 > > > > > > > > There is already a lot of protest against point 2, and I > > > > believe that this is going to be fixed. > > > > > > > > Cheers > > > > James > > > > > > > > ________________________________________ > > > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > > > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > > > > Sent: Thursday, August 12, 2010 3:21 AM > > > > To: sipcore@ietf.org > > > > Subject: [sipcore] Questions on location conveyance and > > > dereferencing > > > > > > > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, > > > > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there > > > > seems to be an absence of specification of what event package > > > > to use when submitting a SIP or SIPS SUBSCRIBE request for > > > > dereference purposes. If it is not defined in this > > > > specification, where is it defined? > > > > > > > > 2. Concerning PRES-URIs, we have the following text in 4.6: > > > > "If a location URI is included in a SIP request, it MUST > > be a SIP-, > > > > SIPS- or PRES-URI. When PRES: is used, as defined in > > > [RFC3856], if > > > > the resulting resolution resolves to a SIP: or SIPS:=20 > URI, this > > > > section applies." > > > > > > > > The words "this section applies" are rather strange, because > > > > there is little else in this section. Maybe in a previous > > > > iteration there was more information here (on how to use a > > > > SIP/SIPS URI for dereference purposes). As things stand, the > > > > absence of information on how to resolve a SIP- or SIPS-URI > > > > applies also to PRES-URIs. > > > > > > > > 3. Also there is nothing to say what to do if the PRES URI > > > > fails to resolve to a SIP or SIPS URI. > > > > > > > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited > > > > above seems to preclude the addition of future URI schemes, > > > > which seems to be in conflict with 8.6 (registry > > > > establishment for location URIs). > > > > > > > > > > > > John > > > > _______________________________________________ > > > > 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 James.Winterbottom@andrew.com Fri Aug 13 02:34:17 2010 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 79C6D3A6851 for ; Fri, 13 Aug 2010 02:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=-0.592, 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 u4-y7-xblbVE for ; Fri, 13 Aug 2010 02:34:16 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id BA9513A68DA for ; Fri, 13 Aug 2010 02:34:15 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:6207 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S351481Ab0HMJew convert rfc822-to-8bit (ORCPT ); Fri, 13 Aug 2010 04:34:52 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 13 Aug 2010 04:34:52 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 13 Aug 2010 17:34:50 +0800 From: "Winterbottom, James" To: "Elwell, John" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "sipcore@ietf.org" Date: Fri, 13 Aug 2010 17:34:49 +0800 Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYwAAUJuAAABop6E= Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AC@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.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: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 09:34:17 -0000 Hi John, Yes, this indeed a tricky one. I must admit that I am biased here. I think that location has a huge range of application beyond just emergency calling, and I think that a lot of this will be implemented over HTTP, HTML5's geolocation capabilities are just one example. So, if we have to standardize on just one scheme being mandatory then I will argue (probably for a very long time) that HTTP and HELD are the best schemes to mandate. But again, this is only one option and one opinion. I do think that supporting multiple schemes in the same header may however resolve something things, if we can agree on a MUST implement scheme. Cheers James ________________________________________ From: Elwell, John [john.elwell@siemens-enterprise.com] Sent: Friday, August 13, 2010 4:25 AM To: Winterbottom, James; Tschofenig, Hannes (NSN - FI/Espoo); sipcore@ietf.org Subject: RE: [sipcore] Questions on location conveyance and dereferencing James, I am not really making a firm proposal, and I am indeed aware of the history of location-conveyance and don't want to go back to the multiple locations model that we had previously. However, for a single location, if there are multiple URI schemes, I see the following possibilities: - limit the number of URI schemes and say the recipient MUST implement all (the ultimate version of this is to have only a single URI scheme); - define a limited number (perhaps just one) of MUST implement URI schemes, and allow the conveyance of multiple URIs with different schemes, all referencing the same location resource, at least one of which is a MUST implement scheme; - have some sort of negotiation mechanism - but I don't want to go there because of adding round-trips, particularly a problem for emergency calls. Any other possibilities? John > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: 13 August 2010 10:14 > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo); > sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and > dereferencing > > Hi John, > > I am inclined to agree that proliferation of URI schemes may > be a problem. I am also inclined to think that there really > aren't that many common URI schemes with multiple > interpretation with regard to how you get location > information from them. I could be wrong here though. > > As far as the HELD side of things go, I was really thinking > that you would get a URI from the LIS that uniquely > identifies the Target/resource, as is described in the > dereference draft. > > Previous revisions of the conveyance draft have allowed > multiple header instances and it would have been possible to > include additional URI schemes by adding abother header. I > don't really want to go back to this scheme. If you are > proposing that a single header may include multiple URI > types, this might work, but I would oppose forcing these to > be directly specified in the ABNF since this would limit > extensibility unnecessarily. > > Cheers > James > ________________________________________ > From: Elwell, John [john.elwell@siemens-enterprise.com] > Sent: Friday, August 13, 2010 4:04 AM > To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; > sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and > dereferencing > > In fact, proliferation of URI schemes is a problem. If we > have n URI schemes standardized for inclusion in the > Geolocation header field, then a recipient would need to > support dereferencing for all n schemes. There is no > negotiation mechanism whereby the inserter can select a > scheme that the recipient is known to support. Sounds like an > interop nightmare. Perhaps we should go as far as limiting it > to a single scheme: HTTPS (using HELD with > identity-extensions)? This would just get you the location, > without the rest of presence. Or perhaps we should allow in > the Geolocation header field several URIs with different > schemes, any of which can reach the same location resource. > > John > > > -----Original Message----- > > From: Tschofenig, Hannes (NSN - FI/Espoo) > > [mailto:hannes.tschofenig@nsn.com] > > Sent: 13 August 2010 09:37 > > To: ext Winterbottom, James; Elwell, John; sipcore@ietf.org > > Subject: RE: [sipcore] Questions on location conveyance and > > dereferencing > > > > Good questions, John! > > > > I don't know why we need SIP/SIPS and the PRES URI scheme. Wouldn't > > SIP/SIPS already be sufficient? > > > > If you only use RFC 3856 then you have no way to filter > location; you > > might end up getting a lot of notifications. Still, it works. > > > > If you use RFC 3856 with the location filters then you can > > additionally > > limit the number of notifications you get. The location > filters works > > reuses RFC 4661 to a certain extend but my intention was that > > you do not > > need to implement the full RFC 4661 for location filtering > because you > > do not need it nor does it seem to be useful either. Using > > RFC 4661 on > > the other hand would not get you too far in the area of location > > filtering. > > > > So, the options are: > > > > A) RFC 3856 > > B) RFC 3856 + loc-filters. > > > > If you send a SUBSCRIBE with loc-filters and the other > party does not > > understand it then the error handling in RFC 3856 should kick in. > > > > Does this make sense to you? > > > > Ciao > > Hannes > > > > PS: With the work on loc-filters I suggested to get rid of RFC 4661 > > completely and to build loc-filters on top of something entirely > > different (for example a scripting language like JavaScript) but the > > group did not like it. > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext > > Winterbottom, James > > > Sent: Friday, August 13, 2010 11:24 AM > > > To: Elwell, John; sipcore@ietf.org > > > Subject: Re: [sipcore] Questions on location conveyance and > > > dereferencing > > > > > > Hi John, > > > > > > Those are valid points. For the most part I have really only > > > been thinking about using HTTP URIs for HELD dereferencing in > > > this header, so I haven't given a whole lot of thought to SIP > > > outside of loc-filters. > > > > > > Do you have a recommendation? > > > > > > Cheers > > > James > > > > > > ________________________________________ > > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > > Sent: Friday, August 13, 2010 3:19 AM > > > To: Winterbottom, James; sipcore@ietf.org > > > Subject: RE: Questions on location conveyance and dereferencing > > > > > > James, > > > > > > Thanks. True, this could be used, but the point is, if I > > > receive a SIP/SIPS-URI in a SIP Geolocation header field, how > > > do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661, > > > RFC 3856 + RFC 4661 + loc-filters, some other event package). > > > Unless something is specified in location-conveyance, how do > > > I, as location recipient, know which event package and > > > extensions are likely to work at the referenced resource? > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: 12 August 2010 09:27 > > > > To: Elwell, John; sipcore@ietf.org > > > > Subject: RE: Questions on location conveyance and dereferencing > > > > > > > > Hi John, > > > > > > > > I think you could use this as a basic location subscription: > > > > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 > > > > > > > > There is already a lot of protest against point 2, and I > > > > believe that this is going to be fixed. > > > > > > > > Cheers > > > > James > > > > > > > > ________________________________________ > > > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > > > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > > > > Sent: Thursday, August 12, 2010 3:21 AM > > > > To: sipcore@ietf.org > > > > Subject: [sipcore] Questions on location conveyance and > > > dereferencing > > > > > > > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, > > > > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there > > > > seems to be an absence of specification of what event package > > > > to use when submitting a SIP or SIPS SUBSCRIBE request for > > > > dereference purposes. If it is not defined in this > > > > specification, where is it defined? > > > > > > > > 2. Concerning PRES-URIs, we have the following text in 4.6: > > > > "If a location URI is included in a SIP request, it MUST > > be a SIP-, > > > > SIPS- or PRES-URI. When PRES: is used, as defined in > > > [RFC3856], if > > > > the resulting resolution resolves to a SIP: or SIPS: > URI, this > > > > section applies." > > > > > > > > The words "this section applies" are rather strange, because > > > > there is little else in this section. Maybe in a previous > > > > iteration there was more information here (on how to use a > > > > SIP/SIPS URI for dereference purposes). As things stand, the > > > > absence of information on how to resolve a SIP- or SIPS-URI > > > > applies also to PRES-URIs. > > > > > > > > 3. Also there is nothing to say what to do if the PRES URI > > > > fails to resolve to a SIP or SIPS URI. > > > > > > > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited > > > > above seems to preclude the addition of future URI schemes, > > > > which seems to be in conflict with 8.6 (registry > > > > establishment for location URIs). > > > > > > > > > > > > John > > > > _______________________________________________ > > > > 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 hannes.tschofenig@nsn.com Fri Aug 13 02:53:01 2010 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 BBC2A3A6878 for ; Fri, 13 Aug 2010 02:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, 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 Q65UnMXm0n6y for ; Fri, 13 Aug 2010 02:53:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 5B46F3A67D7 for ; Fri, 13 Aug 2010 02:52:59 -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 o7D9rVhw024224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Aug 2010 11:53:32 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7D9rSuS006479; Fri, 13 Aug 2010 11:53:31 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Aug 2010 11:53: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: Fri, 13 Aug 2010 12:53:29 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E9BE56@FIESEXC015.nsn-intra.net> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AC@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYwAAUJuAAABop6EAAHVqQA== References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AC@SISPE7MB1.commscope.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Winterbottom, James" , "Elwell, John" , X-OriginalArrivalTime: 13 Aug 2010 09:53:30.0216 (UTC) FILETIME=[624DBE80:01CB3ACD] Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 09:53:01 -0000 John,=20 I believe you make it more complicated than it really is.=20 We have two mechanisms in SIP Location Conveyance, namely one based on SIP and the other one based on HTTP. The two clearly provide different capabilities.=20 For emergency services I suspect that for a very, very long time the different parties will agree, which one they are going to use. The fixed line operators will opt for the HTTP one and maybe the cellular operators will go for the SIP based solution. HTTP will more or less be the baseline.=20 For non-emergency services I doubt that SIP location coneyance will be used anytime in the near future. The reasons is quite simple: some players will continue to struggle with the business model. Additionally, most applications use the HTTP-based web (and not SIP). If you look at the deployment of the W3C geolocation API then you will certainly agree with me and none of the stuff we are discussing here is relevant. Hence, the only solution that is available is an end host based approach; this allows location to be conveyed inband in protocols, such as the Geolocation API. For the non-emergency service use case the "negotiation" is quite simple: You send something that isn't understood by the other party. You get an error back.=20 I hope that answered your question.=20 Ciao Hannes > -----Original Message----- > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 > Sent: Friday, August 13, 2010 12:35 PM > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo);=20 > sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and=20 > dereferencing >=20 > Hi John, >=20 > Yes, this indeed a tricky one. > I must admit that I am biased here. I think that location has=20 > a huge range of application beyond just emergency calling,=20 > and I think that a lot of this will be implemented over HTTP,=20 > HTML5's geolocation capabilities are just one example. So, if=20 > we have to standardize on just one scheme being mandatory=20 > then I will argue (probably for a very long time) that HTTP=20 > and HELD are the best schemes to mandate. >=20 > But again, this is only one option and one opinion. I do=20 > think that supporting multiple schemes in the same header may=20 > however resolve something things, if we can agree on a MUST=20 > implement scheme. >=20 > Cheers > James >=20 > ________________________________________ > From: Elwell, John [john.elwell@siemens-enterprise.com] > Sent: Friday, August 13, 2010 4:25 AM > To: Winterbottom, James; Tschofenig, Hannes (NSN - FI/Espoo);=20 > sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and=20 > dereferencing >=20 > James, >=20 > I am not really making a firm proposal, and I am indeed aware=20 > of the history of location-conveyance and don't want to go=20 > back to the multiple locations model that we had previously.=20 > However, for a single location, if there are multiple URI=20 > schemes, I see the following possibilities: > - limit the number of URI schemes and say the recipient MUST=20 > implement all (the ultimate version of this is to have only a=20 > single URI scheme); > - define a limited number (perhaps just one) of MUST=20 > implement URI schemes, and allow the conveyance of multiple=20 > URIs with different schemes, all referencing the same=20 > location resource, at least one of which is a MUST implement scheme; > - have some sort of negotiation mechanism - but I don't want=20 > to go there because of adding round-trips, particularly a=20 > problem for emergency calls. >=20 > Any other possibilities? >=20 > John >=20 >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: 13 August 2010 10:14 > > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo); > > sipcore@ietf.org > > Subject: RE: [sipcore] Questions on location conveyance and > > dereferencing > > > > Hi John, > > > > I am inclined to agree that proliferation of URI schemes may > > be a problem. I am also inclined to think that there really > > aren't that many common URI schemes with multiple > > interpretation with regard to how you get location > > information from them. I could be wrong here though. > > > > As far as the HELD side of things go, I was really thinking > > that you would get a URI from the LIS that uniquely > > identifies the Target/resource, as is described in the > > dereference draft. > > > > Previous revisions of the conveyance draft have allowed > > multiple header instances and it would have been possible to > > include additional URI schemes by adding abother header. I > > don't really want to go back to this scheme. If you are > > proposing that a single header may include multiple URI > > types, this might work, but I would oppose forcing these to > > be directly specified in the ABNF since this would limit > > extensibility unnecessarily. > > > > Cheers > > James > > ________________________________________ > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > Sent: Friday, August 13, 2010 4:04 AM > > To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; > > sipcore@ietf.org > > Subject: RE: [sipcore] Questions on location conveyance and > > dereferencing > > > > In fact, proliferation of URI schemes is a problem. If we > > have n URI schemes standardized for inclusion in the > > Geolocation header field, then a recipient would need to > > support dereferencing for all n schemes. There is no > > negotiation mechanism whereby the inserter can select a > > scheme that the recipient is known to support. Sounds like an > > interop nightmare. Perhaps we should go as far as limiting it > > to a single scheme: HTTPS (using HELD with > > identity-extensions)? This would just get you the location, > > without the rest of presence. Or perhaps we should allow in > > the Geolocation header field several URIs with different > > schemes, any of which can reach the same location resource. > > > > John > > > > > -----Original Message----- > > > From: Tschofenig, Hannes (NSN - FI/Espoo) > > > [mailto:hannes.tschofenig@nsn.com] > > > Sent: 13 August 2010 09:37 > > > To: ext Winterbottom, James; Elwell, John; sipcore@ietf.org > > > Subject: RE: [sipcore] Questions on location conveyance and > > > dereferencing > > > > > > Good questions, John! > > > > > > I don't know why we need SIP/SIPS and the PRES URI=20 > scheme. Wouldn't > > > SIP/SIPS already be sufficient? > > > > > > If you only use RFC 3856 then you have no way to filter > > location; you > > > might end up getting a lot of notifications. Still, it works. > > > > > > If you use RFC 3856 with the location filters then you can > > > additionally > > > limit the number of notifications you get. The location > > filters works > > > reuses RFC 4661 to a certain extend but my intention was that > > > you do not > > > need to implement the full RFC 4661 for location filtering > > because you > > > do not need it nor does it seem to be useful either. Using > > > RFC 4661 on > > > the other hand would not get you too far in the area of location > > > filtering. > > > > > > So, the options are: > > > > > > A) RFC 3856 > > > B) RFC 3856 + loc-filters. > > > > > > If you send a SUBSCRIBE with loc-filters and the other > > party does not > > > understand it then the error handling in RFC 3856 should kick in. > > > > > > Does this make sense to you? > > > > > > Ciao > > > Hannes > > > > > > PS: With the work on loc-filters I suggested to get rid=20 > of RFC 4661 > > > completely and to build loc-filters on top of something entirely > > > different (for example a scripting language like=20 > JavaScript) but the > > > group did not like it. > > > > > > > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext > > > Winterbottom, James > > > > Sent: Friday, August 13, 2010 11:24 AM > > > > To: Elwell, John; sipcore@ietf.org > > > > Subject: Re: [sipcore] Questions on location conveyance and > > > > dereferencing > > > > > > > > Hi John, > > > > > > > > Those are valid points. For the most part I have really only > > > > been thinking about using HTTP URIs for HELD dereferencing in > > > > this header, so I haven't given a whole lot of thought to SIP > > > > outside of loc-filters. > > > > > > > > Do you have a recommendation? > > > > > > > > Cheers > > > > James > > > > > > > > ________________________________________ > > > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > > > Sent: Friday, August 13, 2010 3:19 AM > > > > To: Winterbottom, James; sipcore@ietf.org > > > > Subject: RE: Questions on location conveyance and dereferencing > > > > > > > > James, > > > > > > > > Thanks. True, this could be used, but the point is, if I > > > > receive a SIP/SIPS-URI in a SIP Geolocation header field, how > > > > do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661, > > > > RFC 3856 + RFC 4661 + loc-filters, some other event package). > > > > Unless something is specified in location-conveyance, how do > > > > I, as location recipient, know which event package and > > > > extensions are likely to work at the referenced resource? > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: Winterbottom, James=20 > [mailto:James.Winterbottom@andrew.com] > > > > > Sent: 12 August 2010 09:27 > > > > > To: Elwell, John; sipcore@ietf.org > > > > > Subject: RE: Questions on location conveyance and=20 > dereferencing > > > > > > > > > > Hi John, > > > > > > > > > > I think you could use this as a basic location subscription: > > > > > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 > > > > > > > > > > There is already a lot of protest against point 2, and I > > > > > believe that this is going to be fixed. > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > ________________________________________ > > > > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > > > > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > > > > > Sent: Thursday, August 12, 2010 3:21 AM > > > > > To: sipcore@ietf.org > > > > > Subject: [sipcore] Questions on location conveyance and > > > > dereferencing > > > > > > > > > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, > > > > > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there > > > > > seems to be an absence of specification of what event package > > > > > to use when submitting a SIP or SIPS SUBSCRIBE request for > > > > > dereference purposes. If it is not defined in this > > > > > specification, where is it defined? > > > > > > > > > > 2. Concerning PRES-URIs, we have the following text in 4.6: > > > > > "If a location URI is included in a SIP request, it MUST > > > be a SIP-, > > > > > SIPS- or PRES-URI. When PRES: is used, as defined in > > > > [RFC3856], if > > > > > the resulting resolution resolves to a SIP: or SIPS: > > URI, this > > > > > section applies." > > > > > > > > > > The words "this section applies" are rather strange, because > > > > > there is little else in this section. Maybe in a previous > > > > > iteration there was more information here (on how to use a > > > > > SIP/SIPS URI for dereference purposes). As things stand, the > > > > > absence of information on how to resolve a SIP- or SIPS-URI > > > > > applies also to PRES-URIs. > > > > > > > > > > 3. Also there is nothing to say what to do if the PRES URI > > > > > fails to resolve to a SIP or SIPS URI. > > > > > > > > > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited > > > > > above seems to preclude the addition of future URI schemes, > > > > > which seems to be in conflict with 8.6 (registry > > > > > establishment for location URIs). > > > > > > > > > > > > > > > John > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > >=20 From john.elwell@siemens-enterprise.com Fri Aug 13 03:14:18 2010 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 2DC653A696B for ; Fri, 13 Aug 2010 03:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.752 X-Spam-Level: X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, 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 QI59goLw6Rhk for ; Fri, 13 Aug 2010 03:14:16 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id B63993A6819 for ; Fri, 13 Aug 2010 03:14:15 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1161498; Fri, 13 Aug 2010 12:14:52 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 0526F1EB82AB; Fri, 13 Aug 2010 12:14:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 13 Aug 2010 12:14:52 +0200 From: "Elwell, John" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Winterbottom, James" , "sipcore@ietf.org" Date: Fri, 13 Aug 2010 12:14:51 +0200 Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYwAAUJuAAABop6EAAHVqQAAAoHrw Message-ID: References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AC@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BE56@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E9BE56@FIESEXC015.nsn-intra.net> 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 Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 10:14:18 -0000 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: 13 August 2010 10:53 > To: ext Winterbottom, James; Elwell, John; sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and > dereferencing > > John, > > I believe you make it more complicated than it really is. > > We have two mechanisms in SIP Location Conveyance, namely one based on > SIP and the other one based on HTTP. The two clearly provide different > capabilities. [JRE] I am not sure what you mean here. If I search location-conveyance for= "HTTP" I don't find it. I assume HTTP is covered by "absoluteURI" in 4.1, = however. In fact there is a conflict - section 4.6 doesn't permit "absolute= " URI - it says a location URI MUST be SIP/SIPS/PRES. Furthermore, section = 8.6 establishes a registry, which allows other URI schemes beyond SIP/SIPS/= PRES to be added - presumably under the umbrella of "absoluteURI", but this= too is in conflict with 4.6. Anyway, my interpretation is that the ability= to use HTTP is intended, but these three sub-sections are certainly in a m= ess and don't give much of a clue to this possibility. A more explicit ment= ion of HTTP(S) would certainly be helpful. > > For emergency services I suspect that for a very, very long time the > different parties will agree, which one they are going to > use. The fixed > line operators will opt for the HTTP one and maybe the cellular > operators will go for the SIP based solution. HTTP will more > or less be > the baseline. [JRE] That in itself is an interop problem. For example, if I deploy an ent= erprise LIS, how do I know whether it should give out HTTP or SIP URIs to i= ts SIP UAs for inclusion in the Geolocation header field? > > For non-emergency services I doubt that SIP location coneyance will be > used anytime in the near future. The reasons is quite simple: some > players will continue to struggle with the business model. > Additionally, > most applications use the HTTP-based web (and not SIP). If you look at > the deployment of the W3C geolocation API then you will > certainly agree > with me and none of the stuff we are discussing here is relevant. [JRE] Yes, and even if applications use presence, they might use XMPP rathe= r than SIMPLE. > > Hence, the only solution that is available is an end host based > approach; this allows location to be conveyed inband in > protocols, such > as the Geolocation API. For the non-emergency service use case the > "negotiation" is quite simple: You send something that isn't > understood > by the other party. You get an error back. [JRE] So you try again with something else, and that fails too - not very s= atisfactory. I think a MUST implement scheme is likely to be the best solut= ion, even if we allow other schemes to be conveyed too. John > > I hope that answered your question. > > Ciao > Hannes > > > -----Original Message----- > > From: ext Winterbottom, James > [mailto:James.Winterbottom@andrew.com] > > Sent: Friday, August 13, 2010 12:35 PM > > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo); > > sipcore@ietf.org > > Subject: RE: [sipcore] Questions on location conveyance and > > dereferencing > > > > Hi John, > > > > Yes, this indeed a tricky one. > > I must admit that I am biased here. I think that location has > > a huge range of application beyond just emergency calling, > > and I think that a lot of this will be implemented over HTTP, > > HTML5's geolocation capabilities are just one example. So, if > > we have to standardize on just one scheme being mandatory > > then I will argue (probably for a very long time) that HTTP > > and HELD are the best schemes to mandate. > > > > But again, this is only one option and one opinion. I do > > think that supporting multiple schemes in the same header may > > however resolve something things, if we can agree on a MUST > > implement scheme. > > > > Cheers > > James > > > > ________________________________________ > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > Sent: Friday, August 13, 2010 4:25 AM > > To: Winterbottom, James; Tschofenig, Hannes (NSN - FI/Espoo); > > sipcore@ietf.org > > Subject: RE: [sipcore] Questions on location conveyance and > > dereferencing > > > > James, > > > > I am not really making a firm proposal, and I am indeed aware > > of the history of location-conveyance and don't want to go > > back to the multiple locations model that we had previously. > > However, for a single location, if there are multiple URI > > schemes, I see the following possibilities: > > - limit the number of URI schemes and say the recipient MUST > > implement all (the ultimate version of this is to have only a > > single URI scheme); > > - define a limited number (perhaps just one) of MUST > > implement URI schemes, and allow the conveyance of multiple > > URIs with different schemes, all referencing the same > > location resource, at least one of which is a MUST implement scheme; > > - have some sort of negotiation mechanism - but I don't want > > to go there because of adding round-trips, particularly a > > problem for emergency calls. > > > > Any other possibilities? > > > > John > > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: 13 August 2010 10:14 > > > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo); > > > sipcore@ietf.org > > > Subject: RE: [sipcore] Questions on location conveyance and > > > dereferencing > > > > > > Hi John, > > > > > > I am inclined to agree that proliferation of URI schemes may > > > be a problem. I am also inclined to think that there really > > > aren't that many common URI schemes with multiple > > > interpretation with regard to how you get location > > > information from them. I could be wrong here though. > > > > > > As far as the HELD side of things go, I was really thinking > > > that you would get a URI from the LIS that uniquely > > > identifies the Target/resource, as is described in the > > > dereference draft. > > > > > > Previous revisions of the conveyance draft have allowed > > > multiple header instances and it would have been possible to > > > include additional URI schemes by adding abother header. I > > > don't really want to go back to this scheme. If you are > > > proposing that a single header may include multiple URI > > > types, this might work, but I would oppose forcing these to > > > be directly specified in the ABNF since this would limit > > > extensibility unnecessarily. > > > > > > Cheers > > > James > > > ________________________________________ > > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > > Sent: Friday, August 13, 2010 4:04 AM > > > To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; > > > sipcore@ietf.org > > > Subject: RE: [sipcore] Questions on location conveyance and > > > dereferencing > > > > > > In fact, proliferation of URI schemes is a problem. If we > > > have n URI schemes standardized for inclusion in the > > > Geolocation header field, then a recipient would need to > > > support dereferencing for all n schemes. There is no > > > negotiation mechanism whereby the inserter can select a > > > scheme that the recipient is known to support. Sounds like an > > > interop nightmare. Perhaps we should go as far as limiting it > > > to a single scheme: HTTPS (using HELD with > > > identity-extensions)? This would just get you the location, > > > without the rest of presence. Or perhaps we should allow in > > > the Geolocation header field several URIs with different > > > schemes, any of which can reach the same location resource. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Tschofenig, Hannes (NSN - FI/Espoo) > > > > [mailto:hannes.tschofenig@nsn.com] > > > > Sent: 13 August 2010 09:37 > > > > To: ext Winterbottom, James; Elwell, John; sipcore@ietf.org > > > > Subject: RE: [sipcore] Questions on location conveyance and > > > > dereferencing > > > > > > > > Good questions, John! > > > > > > > > I don't know why we need SIP/SIPS and the PRES URI > > scheme. Wouldn't > > > > SIP/SIPS already be sufficient? > > > > > > > > If you only use RFC 3856 then you have no way to filter > > > location; you > > > > might end up getting a lot of notifications. Still, it works. > > > > > > > > If you use RFC 3856 with the location filters then you can > > > > additionally > > > > limit the number of notifications you get. The location > > > filters works > > > > reuses RFC 4661 to a certain extend but my intention was that > > > > you do not > > > > need to implement the full RFC 4661 for location filtering > > > because you > > > > do not need it nor does it seem to be useful either. Using > > > > RFC 4661 on > > > > the other hand would not get you too far in the area of location > > > > filtering. > > > > > > > > So, the options are: > > > > > > > > A) RFC 3856 > > > > B) RFC 3856 + loc-filters. > > > > > > > > If you send a SUBSCRIBE with loc-filters and the other > > > party does not > > > > understand it then the error handling in RFC 3856 > should kick in. > > > > > > > > Does this make sense to you? > > > > > > > > Ciao > > > > Hannes > > > > > > > > PS: With the work on loc-filters I suggested to get rid > > of RFC 4661 > > > > completely and to build loc-filters on top of something entirely > > > > different (for example a scripting language like > > JavaScript) but the > > > > group did not like it. > > > > > > > > > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext > > > > Winterbottom, James > > > > > Sent: Friday, August 13, 2010 11:24 AM > > > > > To: Elwell, John; sipcore@ietf.org > > > > > Subject: Re: [sipcore] Questions on location conveyance and > > > > > dereferencing > > > > > > > > > > Hi John, > > > > > > > > > > Those are valid points. For the most part I have really only > > > > > been thinking about using HTTP URIs for HELD dereferencing in > > > > > this header, so I haven't given a whole lot of thought to SIP > > > > > outside of loc-filters. > > > > > > > > > > Do you have a recommendation? > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > ________________________________________ > > > > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > > > > Sent: Friday, August 13, 2010 3:19 AM > > > > > To: Winterbottom, James; sipcore@ietf.org > > > > > Subject: RE: Questions on location conveyance and > dereferencing > > > > > > > > > > James, > > > > > > > > > > Thanks. True, this could be used, but the point is, if I > > > > > receive a SIP/SIPS-URI in a SIP Geolocation header field, how > > > > > do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661, > > > > > RFC 3856 + RFC 4661 + loc-filters, some other event package). > > > > > Unless something is specified in location-conveyance, how do > > > > > I, as location recipient, know which event package and > > > > > extensions are likely to work at the referenced resource? > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Winterbottom, James > > [mailto:James.Winterbottom@andrew.com] > > > > > > Sent: 12 August 2010 09:27 > > > > > > To: Elwell, John; sipcore@ietf.org > > > > > > Subject: RE: Questions on location conveyance and > > dereferencing > > > > > > > > > > > > Hi John, > > > > > > > > > > > > I think you could use this as a basic location subscription: > > > > > > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 > > > > > > > > > > > > There is already a lot of protest against point 2, and I > > > > > > believe that this is going to be fixed. > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > ________________________________________ > > > > > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > > > > > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > > > > > > Sent: Thursday, August 12, 2010 3:21 AM > > > > > > To: sipcore@ietf.org > > > > > > Subject: [sipcore] Questions on location conveyance and > > > > > dereferencing > > > > > > > > > > > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, > > > > > > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there > > > > > > seems to be an absence of specification of what > event package > > > > > > to use when submitting a SIP or SIPS SUBSCRIBE request for > > > > > > dereference purposes. If it is not defined in this > > > > > > specification, where is it defined? > > > > > > > > > > > > 2. Concerning PRES-URIs, we have the following text in 4.6: > > > > > > "If a location URI is included in a SIP request, it MUST > > > > be a SIP-, > > > > > > SIPS- or PRES-URI. When PRES: is used, as defined in > > > > > [RFC3856], if > > > > > > the resulting resolution resolves to a SIP: or SIPS: > > > URI, this > > > > > > section applies." > > > > > > > > > > > > The words "this section applies" are rather strange, because > > > > > > there is little else in this section. Maybe in a previous > > > > > > iteration there was more information here (on how to use a > > > > > > SIP/SIPS URI for dereference purposes). As things stand, the > > > > > > absence of information on how to resolve a SIP- or SIPS-URI > > > > > > applies also to PRES-URIs. > > > > > > > > > > > > 3. Also there is nothing to say what to do if the PRES URI > > > > > > fails to resolve to a SIP or SIPS URI. > > > > > > > > > > > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited > > > > > > above seems to preclude the addition of future URI schemes, > > > > > > which seems to be in conflict with 8.6 (registry > > > > > > establishment for location URIs). > > > > > > > > > > > > > > > > > > John > > > > > > _______________________________________________ > > > > > > 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 James.Winterbottom@andrew.com Fri Aug 13 03:27:21 2010 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 256263A67AF for ; Fri, 13 Aug 2010 03:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.550, 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 pw-OJ14EU54w for ; Fri, 13 Aug 2010 03:27:19 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 32D3C3A696B for ; Fri, 13 Aug 2010 03:27:19 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:34398 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S376763Ab0HMK1x convert rfc822-to-8bit (ORCPT ); Fri, 13 Aug 2010 05:27:53 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 13 Aug 2010 05:27:53 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 13 Aug 2010 18:27:44 +0800 From: "Winterbottom, James" To: "Elwell, John" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "sipcore@ietf.org" Date: Fri, 13 Aug 2010 18:22:48 +0800 Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYwAAUJuAAABop6EAAHVqQAAAoHrwAADMn30= Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AD@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AC@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BE56@FIESEXC015.nsn-intra.net>, 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: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 10:27:21 -0000 Hi John, I thought that I had explained earlier that the prose concerning URI restrictions was going to be lifted some to include HTTP and HTTP(S), and I think that this will be reflected in the ABNF in that absoluteURI will probably be the only type included. James P and Jon P please correct me if this last bit is wrong. When a LIS supporting HELD returns a locationURI, it actually returns a locationUriSet, which contains a set of URIs for different schemes at all point to the same resource. So I think that this addresses your second concern below. On the MUST implement scheme, I have already provided my preference and justified it.... *8) Cheers James ________________________________________ From: Elwell, John [john.elwell@siemens-enterprise.com] Sent: Friday, August 13, 2010 5:14 AM To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; sipcore@ietf.org Subject: RE: [sipcore] Questions on location conveyance and dereferencing > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: 13 August 2010 10:53 > To: ext Winterbottom, James; Elwell, John; sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and > dereferencing > > John, > > I believe you make it more complicated than it really is. > > We have two mechanisms in SIP Location Conveyance, namely one based on > SIP and the other one based on HTTP. The two clearly provide different > capabilities. [JRE] I am not sure what you mean here. If I search location-conveyance for "HTTP" I don't find it. I assume HTTP is covered by "absoluteURI" in 4.1, however. In fact there is a conflict - section 4.6 doesn't permit "absolute" URI - it says a location URI MUST be SIP/SIPS/PRES. Furthermore, section 8.6 establishes a registry, which allows other URI schemes beyond SIP/SIPS/PRES to be added - presumably under the umbrella of "absoluteURI", but this too is in conflict with 4.6. Anyway, my interpretation is that the ability to use HTTP is intended, but these three sub-sections are certainly in a mess and don't give much of a clue to this possibility. A more explicit mention of HTTP(S) would certainly be helpful. > > For emergency services I suspect that for a very, very long time the > different parties will agree, which one they are going to > use. The fixed > line operators will opt for the HTTP one and maybe the cellular > operators will go for the SIP based solution. HTTP will more > or less be > the baseline. [JRE] That in itself is an interop problem. For example, if I deploy an enterprise LIS, how do I know whether it should give out HTTP or SIP URIs to its SIP UAs for inclusion in the Geolocation header field? > > For non-emergency services I doubt that SIP location coneyance will be > used anytime in the near future. The reasons is quite simple: some > players will continue to struggle with the business model. > Additionally, > most applications use the HTTP-based web (and not SIP). If you look at > the deployment of the W3C geolocation API then you will > certainly agree > with me and none of the stuff we are discussing here is relevant. [JRE] Yes, and even if applications use presence, they might use XMPP rather than SIMPLE. > > Hence, the only solution that is available is an end host based > approach; this allows location to be conveyed inband in > protocols, such > as the Geolocation API. For the non-emergency service use case the > "negotiation" is quite simple: You send something that isn't > understood > by the other party. You get an error back. [JRE] So you try again with something else, and that fails too - not very satisfactory. I think a MUST implement scheme is likely to be the best solution, even if we allow other schemes to be conveyed too. John > > I hope that answered your question. > > Ciao > Hannes > > > -----Original Message----- > > From: ext Winterbottom, James > [mailto:James.Winterbottom@andrew.com] > > Sent: Friday, August 13, 2010 12:35 PM > > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo); > > sipcore@ietf.org > > Subject: RE: [sipcore] Questions on location conveyance and > > dereferencing > > > > Hi John, > > > > Yes, this indeed a tricky one. > > I must admit that I am biased here. I think that location has > > a huge range of application beyond just emergency calling, > > and I think that a lot of this will be implemented over HTTP, > > HTML5's geolocation capabilities are just one example. So, if > > we have to standardize on just one scheme being mandatory > > then I will argue (probably for a very long time) that HTTP > > and HELD are the best schemes to mandate. > > > > But again, this is only one option and one opinion. I do > > think that supporting multiple schemes in the same header may > > however resolve something things, if we can agree on a MUST > > implement scheme. > > > > Cheers > > James > > > > ________________________________________ > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > Sent: Friday, August 13, 2010 4:25 AM > > To: Winterbottom, James; Tschofenig, Hannes (NSN - FI/Espoo); > > sipcore@ietf.org > > Subject: RE: [sipcore] Questions on location conveyance and > > dereferencing > > > > James, > > > > I am not really making a firm proposal, and I am indeed aware > > of the history of location-conveyance and don't want to go > > back to the multiple locations model that we had previously. > > However, for a single location, if there are multiple URI > > schemes, I see the following possibilities: > > - limit the number of URI schemes and say the recipient MUST > > implement all (the ultimate version of this is to have only a > > single URI scheme); > > - define a limited number (perhaps just one) of MUST > > implement URI schemes, and allow the conveyance of multiple > > URIs with different schemes, all referencing the same > > location resource, at least one of which is a MUST implement scheme; > > - have some sort of negotiation mechanism - but I don't want > > to go there because of adding round-trips, particularly a > > problem for emergency calls. > > > > Any other possibilities? > > > > John > > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: 13 August 2010 10:14 > > > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo); > > > sipcore@ietf.org > > > Subject: RE: [sipcore] Questions on location conveyance and > > > dereferencing > > > > > > Hi John, > > > > > > I am inclined to agree that proliferation of URI schemes may > > > be a problem. I am also inclined to think that there really > > > aren't that many common URI schemes with multiple > > > interpretation with regard to how you get location > > > information from them. I could be wrong here though. > > > > > > As far as the HELD side of things go, I was really thinking > > > that you would get a URI from the LIS that uniquely > > > identifies the Target/resource, as is described in the > > > dereference draft. > > > > > > Previous revisions of the conveyance draft have allowed > > > multiple header instances and it would have been possible to > > > include additional URI schemes by adding abother header. I > > > don't really want to go back to this scheme. If you are > > > proposing that a single header may include multiple URI > > > types, this might work, but I would oppose forcing these to > > > be directly specified in the ABNF since this would limit > > > extensibility unnecessarily. > > > > > > Cheers > > > James > > > ________________________________________ > > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > > Sent: Friday, August 13, 2010 4:04 AM > > > To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; > > > sipcore@ietf.org > > > Subject: RE: [sipcore] Questions on location conveyance and > > > dereferencing > > > > > > In fact, proliferation of URI schemes is a problem. If we > > > have n URI schemes standardized for inclusion in the > > > Geolocation header field, then a recipient would need to > > > support dereferencing for all n schemes. There is no > > > negotiation mechanism whereby the inserter can select a > > > scheme that the recipient is known to support. Sounds like an > > > interop nightmare. Perhaps we should go as far as limiting it > > > to a single scheme: HTTPS (using HELD with > > > identity-extensions)? This would just get you the location, > > > without the rest of presence. Or perhaps we should allow in > > > the Geolocation header field several URIs with different > > > schemes, any of which can reach the same location resource. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Tschofenig, Hannes (NSN - FI/Espoo) > > > > [mailto:hannes.tschofenig@nsn.com] > > > > Sent: 13 August 2010 09:37 > > > > To: ext Winterbottom, James; Elwell, John; sipcore@ietf.org > > > > Subject: RE: [sipcore] Questions on location conveyance and > > > > dereferencing > > > > > > > > Good questions, John! > > > > > > > > I don't know why we need SIP/SIPS and the PRES URI > > scheme. Wouldn't > > > > SIP/SIPS already be sufficient? > > > > > > > > If you only use RFC 3856 then you have no way to filter > > > location; you > > > > might end up getting a lot of notifications. Still, it works. > > > > > > > > If you use RFC 3856 with the location filters then you can > > > > additionally > > > > limit the number of notifications you get. The location > > > filters works > > > > reuses RFC 4661 to a certain extend but my intention was that > > > > you do not > > > > need to implement the full RFC 4661 for location filtering > > > because you > > > > do not need it nor does it seem to be useful either. Using > > > > RFC 4661 on > > > > the other hand would not get you too far in the area of location > > > > filtering. > > > > > > > > So, the options are: > > > > > > > > A) RFC 3856 > > > > B) RFC 3856 + loc-filters. > > > > > > > > If you send a SUBSCRIBE with loc-filters and the other > > > party does not > > > > understand it then the error handling in RFC 3856 > should kick in. > > > > > > > > Does this make sense to you? > > > > > > > > Ciao > > > > Hannes > > > > > > > > PS: With the work on loc-filters I suggested to get rid > > of RFC 4661 > > > > completely and to build loc-filters on top of something entirely > > > > different (for example a scripting language like > > JavaScript) but the > > > > group did not like it. > > > > > > > > > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext > > > > Winterbottom, James > > > > > Sent: Friday, August 13, 2010 11:24 AM > > > > > To: Elwell, John; sipcore@ietf.org > > > > > Subject: Re: [sipcore] Questions on location conveyance and > > > > > dereferencing > > > > > > > > > > Hi John, > > > > > > > > > > Those are valid points. For the most part I have really only > > > > > been thinking about using HTTP URIs for HELD dereferencing in > > > > > this header, so I haven't given a whole lot of thought to SIP > > > > > outside of loc-filters. > > > > > > > > > > Do you have a recommendation? > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > ________________________________________ > > > > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > > > > Sent: Friday, August 13, 2010 3:19 AM > > > > > To: Winterbottom, James; sipcore@ietf.org > > > > > Subject: RE: Questions on location conveyance and > dereferencing > > > > > > > > > > James, > > > > > > > > > > Thanks. True, this could be used, but the point is, if I > > > > > receive a SIP/SIPS-URI in a SIP Geolocation header field, how > > > > > do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661, > > > > > RFC 3856 + RFC 4661 + loc-filters, some other event package). > > > > > Unless something is specified in location-conveyance, how do > > > > > I, as location recipient, know which event package and > > > > > extensions are likely to work at the referenced resource? > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Winterbottom, James > > [mailto:James.Winterbottom@andrew.com] > > > > > > Sent: 12 August 2010 09:27 > > > > > > To: Elwell, John; sipcore@ietf.org > > > > > > Subject: RE: Questions on location conveyance and > > dereferencing > > > > > > > > > > > > Hi John, > > > > > > > > > > > > I think you could use this as a basic location subscription: > > > > > > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 > > > > > > > > > > > > There is already a lot of protest against point 2, and I > > > > > > believe that this is going to be fixed. > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > ________________________________________ > > > > > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > > > > > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > > > > > > Sent: Thursday, August 12, 2010 3:21 AM > > > > > > To: sipcore@ietf.org > > > > > > Subject: [sipcore] Questions on location conveyance and > > > > > dereferencing > > > > > > > > > > > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, > > > > > > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there > > > > > > seems to be an absence of specification of what > event package > > > > > > to use when submitting a SIP or SIPS SUBSCRIBE request for > > > > > > dereference purposes. If it is not defined in this > > > > > > specification, where is it defined? > > > > > > > > > > > > 2. Concerning PRES-URIs, we have the following text in 4.6: > > > > > > "If a location URI is included in a SIP request, it MUST > > > > be a SIP-, > > > > > > SIPS- or PRES-URI. When PRES: is used, as defined in > > > > > [RFC3856], if > > > > > > the resulting resolution resolves to a SIP: or SIPS: > > > URI, this > > > > > > section applies." > > > > > > > > > > > > The words "this section applies" are rather strange, because > > > > > > there is little else in this section. Maybe in a previous > > > > > > iteration there was more information here (on how to use a > > > > > > SIP/SIPS URI for dereference purposes). As things stand, the > > > > > > absence of information on how to resolve a SIP- or SIPS-URI > > > > > > applies also to PRES-URIs. > > > > > > > > > > > > 3. Also there is nothing to say what to do if the PRES URI > > > > > > fails to resolve to a SIP or SIPS URI. > > > > > > > > > > > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited > > > > > > above seems to preclude the addition of future URI schemes, > > > > > > which seems to be in conflict with 8.6 (registry > > > > > > establishment for location URIs). > > > > > > > > > > > > > > > > > > John > > > > > > _______________________________________________ > > > > > > 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 hannes.tschofenig@nsn.com Fri Aug 13 03:40:47 2010 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 269173A68D2 for ; Fri, 13 Aug 2010 03:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, 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 cTtfpytbFpuc for ; Fri, 13 Aug 2010 03:40:45 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 1B08D3A67AF for ; Fri, 13 Aug 2010 03:40:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7DAfFKl002683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Aug 2010 12:41:15 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7DAfEv9016644; Fri, 13 Aug 2010 12:41:15 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Aug 2010 12:41: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: Fri, 13 Aug 2010 13:41:05 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E9BEBD@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYwAAUJuAAABop6EAAHVqQAAAoHrwAAE+BsA= References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AC@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BE56@FIESEXC015.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Elwell, John" , "ext Winterbottom, James" , X-OriginalArrivalTime: 13 Aug 2010 10:41:07.0573 (UTC) FILETIME=[096BD250:01CB3AD4] Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 10:40:47 -0000 Hi John,=20 =20 > > John, > > > > I believe you make it more complicated than it really is. > > > > We have two mechanisms in SIP Location Conveyance, namely=20 > one based on > > SIP and the other one based on HTTP. The two clearly=20 > provide different > > capabilities. > [JRE] I am not sure what you mean here. If I search=20 > location-conveyance for "HTTP" I don't find it. James Polk forgot to add it for a couple of years. We managed to clarify this aspect recently on the mailing list.=20 The next version of the draft (which will hopefully show up before the next IETF meeting) was promised for this month.=20 =20 > > For emergency services I suspect that for a very, very long time the > > different parties will agree, which one they are going to > > use. The fixed > > line operators will opt for the HTTP one and maybe the cellular > > operators will go for the SIP based solution. HTTP will more > > or less be > > the baseline. > [JRE] That in itself is an interop problem. For example, if I=20 > deploy an enterprise LIS, how do I know whether it should=20 > give out HTTP or SIP URIs to its SIP UAs for inclusion in the=20 > Geolocation header field? In your enterprise LIS for emergency services you will most likely want to figure out who is going to consume that reference. Quite likely the PSAP will consume the reference. If so, you better talk to the PSAP responsible for that specific area.=20 >=20 > > > > For non-emergency services I doubt that SIP location=20 > coneyance will be > > used anytime in the near future. The reasons is quite simple: some > > players will continue to struggle with the business model. > > Additionally, > > most applications use the HTTP-based web (and not SIP). If=20 > you look at > > the deployment of the W3C geolocation API then you will > > certainly agree > > with me and none of the stuff we are discussing here is relevant. > [JRE] Yes, and even if applications use presence, they might=20 > use XMPP rather than SIMPLE. XMPP does not provide equivalent functionality of SIP location conveyance.=20 So, another non-issue.=20 >=20 > > > > Hence, the only solution that is available is an end host based > > approach; this allows location to be conveyed inband in > > protocols, such > > as the Geolocation API. For the non-emergency service use case the > > "negotiation" is quite simple: You send something that isn't > > understood > > by the other party. You get an error back. > [JRE] So you try again with something else, and that fails=20 > too - not very satisfactory. I think a MUST implement scheme=20 > is likely to be the best solution, even if we allow other=20 > schemes to be conveyed too. That's not uncommon for the Web today either. If you get a reference that you cannot resolve then it fails.=20 I have no problem with an extension to HELD asking for a specific type of reference. Providing both references, a SIP and an HTTP based reference, back to the end host is not out of question either.=20 Ciao Hannes >=20 > John >=20 >=20 > > > > I hope that answered your question. > > > > Ciao > > Hannes > > > > > -----Original Message----- > > > From: ext Winterbottom, James > > [mailto:James.Winterbottom@andrew.com] > > > Sent: Friday, August 13, 2010 12:35 PM > > > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo); > > > sipcore@ietf.org > > > Subject: RE: [sipcore] Questions on location conveyance and > > > dereferencing > > > > > > Hi John, > > > > > > Yes, this indeed a tricky one. > > > I must admit that I am biased here. I think that location has > > > a huge range of application beyond just emergency calling, > > > and I think that a lot of this will be implemented over HTTP, > > > HTML5's geolocation capabilities are just one example. So, if > > > we have to standardize on just one scheme being mandatory > > > then I will argue (probably for a very long time) that HTTP > > > and HELD are the best schemes to mandate. > > > > > > But again, this is only one option and one opinion. I do > > > think that supporting multiple schemes in the same header may > > > however resolve something things, if we can agree on a MUST > > > implement scheme. > > > > > > Cheers > > > James > > > > > > ________________________________________ > > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > > Sent: Friday, August 13, 2010 4:25 AM > > > To: Winterbottom, James; Tschofenig, Hannes (NSN - FI/Espoo); > > > sipcore@ietf.org > > > Subject: RE: [sipcore] Questions on location conveyance and > > > dereferencing > > > > > > James, > > > > > > I am not really making a firm proposal, and I am indeed aware > > > of the history of location-conveyance and don't want to go > > > back to the multiple locations model that we had previously. > > > However, for a single location, if there are multiple URI > > > schemes, I see the following possibilities: > > > - limit the number of URI schemes and say the recipient MUST > > > implement all (the ultimate version of this is to have only a > > > single URI scheme); > > > - define a limited number (perhaps just one) of MUST > > > implement URI schemes, and allow the conveyance of multiple > > > URIs with different schemes, all referencing the same > > > location resource, at least one of which is a MUST=20 > implement scheme; > > > - have some sort of negotiation mechanism - but I don't want > > > to go there because of adding round-trips, particularly a > > > problem for emergency calls. > > > > > > Any other possibilities? > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: 13 August 2010 10:14 > > > > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo); > > > > sipcore@ietf.org > > > > Subject: RE: [sipcore] Questions on location conveyance and > > > > dereferencing > > > > > > > > Hi John, > > > > > > > > I am inclined to agree that proliferation of URI schemes may > > > > be a problem. I am also inclined to think that there really > > > > aren't that many common URI schemes with multiple > > > > interpretation with regard to how you get location > > > > information from them. I could be wrong here though. > > > > > > > > As far as the HELD side of things go, I was really thinking > > > > that you would get a URI from the LIS that uniquely > > > > identifies the Target/resource, as is described in the > > > > dereference draft. > > > > > > > > Previous revisions of the conveyance draft have allowed > > > > multiple header instances and it would have been possible to > > > > include additional URI schemes by adding abother header. I > > > > don't really want to go back to this scheme. If you are > > > > proposing that a single header may include multiple URI > > > > types, this might work, but I would oppose forcing these to > > > > be directly specified in the ABNF since this would limit > > > > extensibility unnecessarily. > > > > > > > > Cheers > > > > James > > > > ________________________________________ > > > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > > > Sent: Friday, August 13, 2010 4:04 AM > > > > To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; > > > > sipcore@ietf.org > > > > Subject: RE: [sipcore] Questions on location conveyance and > > > > dereferencing > > > > > > > > In fact, proliferation of URI schemes is a problem. If we > > > > have n URI schemes standardized for inclusion in the > > > > Geolocation header field, then a recipient would need to > > > > support dereferencing for all n schemes. There is no > > > > negotiation mechanism whereby the inserter can select a > > > > scheme that the recipient is known to support. Sounds like an > > > > interop nightmare. Perhaps we should go as far as limiting it > > > > to a single scheme: HTTPS (using HELD with > > > > identity-extensions)? This would just get you the location, > > > > without the rest of presence. Or perhaps we should allow in > > > > the Geolocation header field several URIs with different > > > > schemes, any of which can reach the same location resource. > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Tschofenig, Hannes (NSN - FI/Espoo) > > > > > [mailto:hannes.tschofenig@nsn.com] > > > > > Sent: 13 August 2010 09:37 > > > > > To: ext Winterbottom, James; Elwell, John; sipcore@ietf.org > > > > > Subject: RE: [sipcore] Questions on location conveyance and > > > > > dereferencing > > > > > > > > > > Good questions, John! > > > > > > > > > > I don't know why we need SIP/SIPS and the PRES URI > > > scheme. Wouldn't > > > > > SIP/SIPS already be sufficient? > > > > > > > > > > If you only use RFC 3856 then you have no way to filter > > > > location; you > > > > > might end up getting a lot of notifications. Still, it works. > > > > > > > > > > If you use RFC 3856 with the location filters then you can > > > > > additionally > > > > > limit the number of notifications you get. The location > > > > filters works > > > > > reuses RFC 4661 to a certain extend but my intention was that > > > > > you do not > > > > > need to implement the full RFC 4661 for location filtering > > > > because you > > > > > do not need it nor does it seem to be useful either. Using > > > > > RFC 4661 on > > > > > the other hand would not get you too far in the area=20 > of location > > > > > filtering. > > > > > > > > > > So, the options are: > > > > > > > > > > A) RFC 3856 > > > > > B) RFC 3856 + loc-filters. > > > > > > > > > > If you send a SUBSCRIBE with loc-filters and the other > > > > party does not > > > > > understand it then the error handling in RFC 3856 > > should kick in. > > > > > > > > > > Does this make sense to you? > > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > > > PS: With the work on loc-filters I suggested to get rid > > > of RFC 4661 > > > > > completely and to build loc-filters on top of=20 > something entirely > > > > > different (for example a scripting language like > > > JavaScript) but the > > > > > group did not like it. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: sipcore-bounces@ietf.org > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext > > > > > Winterbottom, James > > > > > > Sent: Friday, August 13, 2010 11:24 AM > > > > > > To: Elwell, John; sipcore@ietf.org > > > > > > Subject: Re: [sipcore] Questions on location conveyance and > > > > > > dereferencing > > > > > > > > > > > > Hi John, > > > > > > > > > > > > Those are valid points. For the most part I have really only > > > > > > been thinking about using HTTP URIs for HELD=20 > dereferencing in > > > > > > this header, so I haven't given a whole lot of=20 > thought to SIP > > > > > > outside of loc-filters. > > > > > > > > > > > > Do you have a recommendation? > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > ________________________________________ > > > > > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > > > > > Sent: Friday, August 13, 2010 3:19 AM > > > > > > To: Winterbottom, James; sipcore@ietf.org > > > > > > Subject: RE: Questions on location conveyance and > > dereferencing > > > > > > > > > > > > James, > > > > > > > > > > > > Thanks. True, this could be used, but the point is, if I > > > > > > receive a SIP/SIPS-URI in a SIP Geolocation header=20 > field, how > > > > > > do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661, > > > > > > RFC 3856 + RFC 4661 + loc-filters, some other event=20 > package). > > > > > > Unless something is specified in location-conveyance, how do > > > > > > I, as location recipient, know which event package and > > > > > > extensions are likely to work at the referenced resource? > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Winterbottom, James > > > [mailto:James.Winterbottom@andrew.com] > > > > > > > Sent: 12 August 2010 09:27 > > > > > > > To: Elwell, John; sipcore@ietf.org > > > > > > > Subject: RE: Questions on location conveyance and > > > dereferencing > > > > > > > > > > > > > > Hi John, > > > > > > > > > > > > > > I think you could use this as a basic location=20 > subscription: > > > > > > >=20 > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11 > > > > > > > > > > > > > > There is already a lot of protest against point 2, and I > > > > > > > believe that this is going to be fixed. > > > > > > > > > > > > > > Cheers > > > > > > > James > > > > > > > > > > > > > > ________________________________________ > > > > > > > From: sipcore-bounces@ietf.org=20 > [sipcore-bounces@ietf.org] On > > > > > > > Behalf Of Elwell, John=20 > [john.elwell@siemens-enterprise.com] > > > > > > > Sent: Thursday, August 12, 2010 3:21 AM > > > > > > > To: sipcore@ietf.org > > > > > > > Subject: [sipcore] Questions on location conveyance and > > > > > > dereferencing > > > > > > > > > > > > > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES, > > > > > > > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there > > > > > > > seems to be an absence of specification of what > > event package > > > > > > > to use when submitting a SIP or SIPS SUBSCRIBE request for > > > > > > > dereference purposes. If it is not defined in this > > > > > > > specification, where is it defined? > > > > > > > > > > > > > > 2. Concerning PRES-URIs, we have the following=20 > text in 4.6: > > > > > > > "If a location URI is included in a SIP request, it MUST > > > > > be a SIP-, > > > > > > > SIPS- or PRES-URI. When PRES: is used, as defined in > > > > > > [RFC3856], if > > > > > > > the resulting resolution resolves to a SIP: or SIPS: > > > > URI, this > > > > > > > section applies." > > > > > > > > > > > > > > The words "this section applies" are rather=20 > strange, because > > > > > > > there is little else in this section. Maybe in a previous > > > > > > > iteration there was more information here (on how to use a > > > > > > > SIP/SIPS URI for dereference purposes). As things=20 > stand, the > > > > > > > absence of information on how to resolve a SIP-=20 > or SIPS-URI > > > > > > > applies also to PRES-URIs. > > > > > > > > > > > > > > 3. Also there is nothing to say what to do if the PRES URI > > > > > > > fails to resolve to a SIP or SIPS URI. > > > > > > > > > > > > > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited > > > > > > > above seems to preclude the addition of future=20 > URI schemes, > > > > > > > which seems to be in conflict with 8.6 (registry > > > > > > > establishment for location URIs). > > > > > > > > > > > > > > > > > > > > > John > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > >=20 From john.elwell@siemens-enterprise.com Fri Aug 13 07:39:20 2010 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 51ADC3A68F8 for ; Fri, 13 Aug 2010 07:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.75 X-Spam-Level: X-Spam-Status: No, score=-102.75 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, 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 n3W4d4gYvjIE for ; Fri, 13 Aug 2010 07:39:14 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 685783A6838 for ; Fri, 13 Aug 2010 07:39:13 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1165461; Fri, 13 Aug 2010 16:39:48 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 6D10D1EB82AB; Fri, 13 Aug 2010 16:39:48 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 13 Aug 2010 16:39:48 +0200 From: "Elwell, John" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Winterbottom, James" , "sipcore@ietf.org" Date: Fri, 13 Aug 2010 16:39:47 +0200 Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYwAAUJuAAABop6EAAHVqQAAAoHrwAAE+BsAAAt1BgA== Message-ID: References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AC@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BE56@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B4502E9BEBD@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E9BEBD@FIESEXC015.nsn-intra.net> 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 Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 13 Aug 2010 14:39:20 -0000 =20 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo)=20 > [mailto:hannes.tschofenig@nsn.com]=20 > Sent: 13 August 2010 11:41 > To: Elwell, John; ext Winterbottom, James; sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and=20 > dereferencing >=20 > Hi John,=20 > =20 >=20 > > > John, > > > > > > I believe you make it more complicated than it really is. > > > > > > We have two mechanisms in SIP Location Conveyance, namely=20 > > one based on > > > SIP and the other one based on HTTP. The two clearly=20 > > provide different > > > capabilities. > > [JRE] I am not sure what you mean here. If I search=20 > > location-conveyance for "HTTP" I don't find it. >=20 > James Polk forgot to add it for a couple of years. We managed=20 > to clarify > this aspect recently on the mailing list.=20 > The next version of the draft (which will hopefully show up before the > next IETF meeting) was promised for this month.=20 [JRE] Yes, of course, I recall now that there was some clarification on the= mailing list in this area. > =20 >=20 > > > For emergency services I suspect that for a very, very=20 > long time the > > > different parties will agree, which one they are going to > > > use. The fixed > > > line operators will opt for the HTTP one and maybe the cellular > > > operators will go for the SIP based solution. HTTP will more > > > or less be > > > the baseline. > > [JRE] That in itself is an interop problem. For example, if I=20 > > deploy an enterprise LIS, how do I know whether it should=20 > > give out HTTP or SIP URIs to its SIP UAs for inclusion in the=20 > > Geolocation header field? >=20 > In your enterprise LIS for emergency services you will most=20 > likely want > to figure out who is going to consume that reference. Quite likely the > PSAP will consume the reference. If so, you better talk to the PSAP > responsible for that specific area.=20 [JRE] Quite so, except is it likely my VoIP service provider might also wan= t to inspect the location, to confirm correct routing? Then depending on wh= ich SP I choose to route that particular call through, they might support d= ifferent URI schemes? It seems to be a mess not having a MUST implement sch= eme. >=20 > >=20 > > > > > > For non-emergency services I doubt that SIP location=20 > > coneyance will be > > > used anytime in the near future. The reasons is quite simple: some > > > players will continue to struggle with the business model. > > > Additionally, > > > most applications use the HTTP-based web (and not SIP). If=20 > > you look at > > > the deployment of the W3C geolocation API then you will > > > certainly agree > > > with me and none of the stuff we are discussing here is relevant. > > [JRE] Yes, and even if applications use presence, they might=20 > > use XMPP rather than SIMPLE. >=20 > XMPP does not provide equivalent functionality of SIP location > conveyance.=20 > So, another non-issue.=20 [JRE] That was not the point I was making. I was simply saying that even ap= plications that support presence might support XMPP rather than SIMPLE, and= therefore would not want to implement RFC 3856. Instead they might prefer = to use HTTP. John From hannes.tschofenig@nsn.com Sun Aug 15 23:26:29 2010 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 AA3473A6819 for ; Sun, 15 Aug 2010 23:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, 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 r2C8rfMIhT3b for ; Sun, 15 Aug 2010 23:26:28 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 37CB53A68B8 for ; Sun, 15 Aug 2010 23:26:27 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7G6QwJ2026377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Aug 2010 08:26:58 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7G6QvHO000871; Mon, 16 Aug 2010 08:26:58 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Aug 2010 08:26: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, 16 Aug 2010 09:26:57 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E9C319@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYwAAUJuAAABop6EAAHVqQAAAoHrwAAE+BsAAAt1BgAAt+KYA References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AC@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BE56@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B4502E9BEBD@FIESEXC015.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Elwell, John" , "ext Winterbottom, James" , X-OriginalArrivalTime: 16 Aug 2010 06:26:57.0743 (UTC) FILETIME=[070DADF0:01CB3D0C] Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 16 Aug 2010 06:26:29 -0000 Hi John,=20 =20 > > In your enterprise LIS for emergency services you will most=20 > > likely want > > to figure out who is going to consume that reference. Quite=20 > likely the > > PSAP will consume the reference. If so, you better talk to the PSAP > > responsible for that specific area.=20 > [JRE] Quite so, except is it likely my VoIP service provider=20 > might also want to inspect the location, to confirm correct=20 > routing? Then depending on which SP I choose to route that=20 > particular call through, they might support different URI=20 > schemes? It seems to be a mess not having a MUST implement scheme. I understand the theoretical concern.=20 I have no objections against a mandatory to implement HTTP-based dereferencing mechanism.=20 > > XMPP does not provide equivalent functionality of SIP location > > conveyance.=20 > > So, another non-issue.=20 > [JRE] That was not the point I was making. I was simply=20 > saying that even applications that support presence might=20 > support XMPP rather than SIMPLE, and therefore would not want=20 > to implement RFC 3856. Instead they might prefer to use HTTP. I am not quite sure which scenario you have in mind.=20 If I have an end host that supports XMPP and then gets a location URI then there is the question of who is going to dereference it. If it is the end point then it would have to implement the protocol indicated by the URI scheme. Now, if this happens to be SIP then this end point would have to implement SIP. The end host could, however, request location by value instead instead of going through the dance of utilizing a LbyR.=20 If the end point does not dereference the LbyR but instead some other entity then there is the question of how this reference then actually gets there.=20 Ciao Hannes From adam@nostrum.com Mon Aug 16 14:28:38 2010 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 6ADBD3A6834 for ; Mon, 16 Aug 2010 14:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, SPF_PASS=-0.001, 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 QSspp6mz5FNq for ; Mon, 16 Aug 2010 14:28:37 -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 4065E3A681E for ; Mon, 16 Aug 2010 14:28:37 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o7GLTCe0078189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Aug 2010 16:29:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C69ADA8.1010802@nostrum.com> Date: Mon, 16 Aug 2010 16:29:12 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" 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] WGLC: draft-ietf-sipcore-rfc4244bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 21:28:38 -0000 [as chair] A major author of draft-ietf-sipcore-rfc4244bis-01 believes that the document has no remaining open issues, and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Tuesday, August 31st. The latest version of the document can be retrieved here: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis Any comments on the document should be sent to the SIPCORE mailing list. /a From Martin.Thomson@andrew.com Mon Aug 16 17:25:54 2010 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 B57C33A6800 for ; Mon, 16 Aug 2010 17:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.055 X-Spam-Level: X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[AWL=-0.456, 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 r26jSvC5W0Xz for ; Mon, 16 Aug 2010 17:25:53 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 8C0C73A67F2 for ; Mon, 16 Aug 2010 17:25:53 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:34571 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S30518317Ab0HQA02 (ORCPT ); Mon, 16 Aug 2010 19:26:28 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 16 Aug 2010 19:26:28 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 17 Aug 2010 08:26:26 +0800 From: "Thomson, Martin" To: "Elwell, John" , "Winterbottom, James" , "sipcore@ietf.org" Date: Tue, 17 Aug 2010 08:28:45 +0800 Thread-Topic: Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAQxtwALgz38A= Message-ID: <8B0A9FCBB9832F43971E38010638454F03ED35A9E7@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 17 Aug 2010 00:25:54 -0000 QXJlbid0IHRoZXNlIGFsbCBmb3J3YXJkIGFuZCBiYWNrd2FyZCBjb21wYXRpYmxlPw0KDQpUaHVz LCBJIGhhZCBhbHdheXMgYXNzdW1lZCB0aGF0IHlvdSBwcm92aWRlIGEgc3Vic2NyaXB0aW9uIHdp dGggdGhlIG1pbmltdW0gc2V0IG9mIGZlYXR1cmVzIHRoYXQgeW91IG5lZWQuICBNb3JlIGFkdmFu Y2VkIGZlYXR1cmVzIGFyZSBjb252ZW5pZW50bHkgaWdub3JlZCBieSB0aGUgUEEuDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgRWx3ZWxs LCBKb2huDQo+IFNlbnQ6IEZyaWRheSwgMTMgQXVndXN0IDIwMTAgNjozNSBQTQ0KPiBUbzogV2lu dGVyYm90dG9tLCBKYW1lczsgc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNv cmVdIFF1ZXN0aW9ucyBvbiBsb2NhdGlvbiBjb252ZXlhbmNlIGFuZA0KPiBkZXJlZmVyZW5jaW5n DQo+IA0KPiBJdCBzZWVtcyB0byBtZSB3ZSBzaG91bGQgbWFuZGF0ZSB0aGF0IFJGQyAzODU2IGJl IHVzZWQuIEkgZG9uJ3QgaGF2ZSBhbg0KPiBvcGluaW9uIGFzIHRvIHdoYXQsIGlmIGFueXRoaW5n LCB3ZSBzaG91bGQgc2F5IGFib3V0IFJGQyA0NjYxLCBsb2MtDQo+IGZpbHRlcnMsIGV0Yy4uDQo+ IA0KPiBKb2huDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IFdpbnRlcmJvdHRvbSwgSmFtZXMgW21haWx0bzpKYW1lcy5XaW50ZXJib3R0b21AYW5kcmV3 LmNvbV0NCj4gPiBTZW50OiAxMyBBdWd1c3QgMjAxMCAwOToyNA0KPiA+IFRvOiBFbHdlbGwsIEpv aG47IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogUXVlc3Rpb25zIG9uIGxvY2F0 aW9uIGNvbnZleWFuY2UgYW5kIGRlcmVmZXJlbmNpbmcNCj4gPg0KPiA+IEhpIEpvaG4sDQo+ID4N Cj4gPiBUaG9zZSBhcmUgdmFsaWQgcG9pbnRzLiBGb3IgdGhlIG1vc3QgcGFydCBJIGhhdmUgcmVh bGx5IG9ubHkNCj4gPiBiZWVuIHRoaW5raW5nIGFib3V0IHVzaW5nIEhUVFAgVVJJcyBmb3IgSEVM RCBkZXJlZmVyZW5jaW5nIGluDQo+ID4gdGhpcyBoZWFkZXIsIHNvIEkgaGF2ZW4ndCBnaXZlbiBh IHdob2xlIGxvdCBvZiB0aG91Z2h0IHRvIFNJUA0KPiA+IG91dHNpZGUgb2YgbG9jLWZpbHRlcnMu DQo+ID4NCj4gPiBEbyB5b3UgaGF2ZSBhIHJlY29tbWVuZGF0aW9uPw0KPiA+DQo+ID4gQ2hlZXJz DQo+ID4gSmFtZXMNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBGcm9tOiBFbHdlbGwsIEpvaG4gW2pvaG4uZWx3ZWxsQHNpZW1lbnMtZW50ZXJw cmlzZS5jb21dDQo+ID4gU2VudDogRnJpZGF5LCBBdWd1c3QgMTMsIDIwMTAgMzoxOSBBTQ0KPiA+ IFRvOiBXaW50ZXJib3R0b20sIEphbWVzOyBzaXBjb3JlQGlldGYub3JnDQo+ID4gU3ViamVjdDog UkU6IFF1ZXN0aW9ucyBvbiBsb2NhdGlvbiBjb252ZXlhbmNlIGFuZCBkZXJlZmVyZW5jaW5nDQo+ ID4NCj4gPiBKYW1lcywNCj4gPg0KPiA+IFRoYW5rcy4gVHJ1ZSwgdGhpcyBjb3VsZCBiZSB1c2Vk LCBidXQgdGhlIHBvaW50IGlzLCBpZiBJDQo+ID4gcmVjZWl2ZSBhIFNJUC9TSVBTLVVSSSBpbiBh IFNJUCBHZW9sb2NhdGlvbiBoZWFkZXIgZmllbGQsIGhvdw0KPiA+IGRvIEkga25vdyB3aGF0IHRv IHVzZSAoZS5nLiwgUkZDIDM4NTYsIFJGQyAzODU2ICsgUkZDIDQ2NjEsDQo+ID4gUkZDIDM4NTYg KyBSRkMgNDY2MSArIGxvYy1maWx0ZXJzLCBzb21lIG90aGVyIGV2ZW50IHBhY2thZ2UpLg0KPiA+ IFVubGVzcyBzb21ldGhpbmcgaXMgc3BlY2lmaWVkIGluIGxvY2F0aW9uLWNvbnZleWFuY2UsIGhv dyBkbw0KPiA+IEksIGFzIGxvY2F0aW9uIHJlY2lwaWVudCwga25vdyB3aGljaCBldmVudCBwYWNr YWdlIGFuZA0KPiA+IGV4dGVuc2lvbnMgYXJlIGxpa2VseSB0byB3b3JrIGF0IHRoZSByZWZlcmVu Y2VkIHJlc291cmNlPw0KPiA+DQo+ID4gSm9obg0KPiA+DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXaW50ZXJib3R0b20sIEphbWVzIFttYWlsdG86 SmFtZXMuV2ludGVyYm90dG9tQGFuZHJldy5jb21dDQo+ID4gPiBTZW50OiAxMiBBdWd1c3QgMjAx MCAwOToyNw0KPiA+ID4gVG86IEVsd2VsbCwgSm9objsgc2lwY29yZUBpZXRmLm9yZw0KPiA+ID4g U3ViamVjdDogUkU6IFF1ZXN0aW9ucyBvbiBsb2NhdGlvbiBjb252ZXlhbmNlIGFuZCBkZXJlZmVy ZW5jaW5nDQo+ID4gPg0KPiA+ID4gSGkgSm9obiwNCj4gPiA+DQo+ID4gPiBJIHRoaW5rIHlvdSBj b3VsZCB1c2UgdGhpcyBhcyBhIGJhc2ljIGxvY2F0aW9uIHN1YnNjcmlwdGlvbjoNCj4gPiA+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZ2VvcHJpdi1sb2MtZmlsdGVycy0x MQ0KPiA+ID4NCj4gPiA+IFRoZXJlIGlzIGFscmVhZHkgYSBsb3Qgb2YgcHJvdGVzdCBhZ2FpbnN0 IHBvaW50IDIsIGFuZCBJDQo+ID4gPiBiZWxpZXZlIHRoYXQgdGhpcyBpcyBnb2luZyB0byBiZSBm aXhlZC4NCj4gPiA+DQo+ID4gPiBDaGVlcnMNCj4gPiA+IEphbWVzDQo+ID4gPg0KPiA+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRnJvbTogc2lwY29y ZS1ib3VuY2VzQGlldGYub3JnIFtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gPiBC ZWhhbGYgT2YgRWx3ZWxsLCBKb2huIFtqb2huLmVsd2VsbEBzaWVtZW5zLWVudGVycHJpc2UuY29t XQ0KPiA+ID4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMiwgMjAxMCAzOjIxIEFNDQo+ID4gPiBU bzogc2lwY29yZUBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogW3NpcGNvcmVdIFF1ZXN0aW9ucyBv biBsb2NhdGlvbiBjb252ZXlhbmNlIGFuZA0KPiA+IGRlcmVmZXJlbmNpbmcNCj4gPiA+DQo+ID4g PiAxLiBEcmFmdC1pZXRmLXNpcGNvcmUtbG9jYXRpb24tY29udmV5YW5jZS0wMyBkZWZpbmVzIFBS RVMsDQo+ID4gPiBTSVAgYW5kIFNJUFMgVVJJIHNjaGVtZXMgZm9yIExieVIuIEZvciBTSVAgYW5k IFNJUFMsIHRoZXJlDQo+ID4gPiBzZWVtcyB0byBiZSBhbiBhYnNlbmNlIG9mIHNwZWNpZmljYXRp b24gb2Ygd2hhdCBldmVudCBwYWNrYWdlDQo+ID4gPiB0byB1c2Ugd2hlbiBzdWJtaXR0aW5nIGEg U0lQIG9yIFNJUFMgU1VCU0NSSUJFIHJlcXVlc3QgZm9yDQo+ID4gPiBkZXJlZmVyZW5jZSBwdXJw b3Nlcy4gSWYgaXQgaXMgbm90IGRlZmluZWQgaW4gdGhpcw0KPiA+ID4gc3BlY2lmaWNhdGlvbiwg d2hlcmUgaXMgaXQgZGVmaW5lZD8NCj4gPiA+DQo+ID4gPiAyLiBDb25jZXJuaW5nIFBSRVMtVVJJ cywgd2UgaGF2ZSB0aGUgZm9sbG93aW5nIHRleHQgaW4gNC42Og0KPiA+ID4gIklmIGEgbG9jYXRp b24gVVJJIGlzIGluY2x1ZGVkIGluIGEgU0lQIHJlcXVlc3QsIGl0IE1VU1QgYmUgYSBTSVAtLA0K PiA+ID4gICAgU0lQUy0gb3IgUFJFUy1VUkkuICBXaGVuIFBSRVM6IGlzIHVzZWQsIGFzIGRlZmlu ZWQgaW4NCj4gPiBbUkZDMzg1Nl0sIGlmDQo+ID4gPiAgICB0aGUgcmVzdWx0aW5nIHJlc29sdXRp b24gcmVzb2x2ZXMgdG8gYSBTSVA6IG9yIFNJUFM6IFVSSSwgdGhpcw0KPiA+ID4gICAgc2VjdGlv biBhcHBsaWVzLiINCj4gPiA+DQo+ID4gPiBUaGUgd29yZHMgInRoaXMgc2VjdGlvbiBhcHBsaWVz IiBhcmUgcmF0aGVyIHN0cmFuZ2UsIGJlY2F1c2UNCj4gPiA+IHRoZXJlIGlzIGxpdHRsZSBlbHNl IGluIHRoaXMgc2VjdGlvbi4gTWF5YmUgaW4gYSBwcmV2aW91cw0KPiA+ID4gaXRlcmF0aW9uIHRo ZXJlIHdhcyBtb3JlIGluZm9ybWF0aW9uIGhlcmUgKG9uIGhvdyB0byB1c2UgYQ0KPiA+ID4gU0lQ L1NJUFMgVVJJIGZvciBkZXJlZmVyZW5jZSBwdXJwb3NlcykuIEFzIHRoaW5ncyBzdGFuZCwgdGhl DQo+ID4gPiBhYnNlbmNlIG9mIGluZm9ybWF0aW9uIG9uIGhvdyB0byByZXNvbHZlIGEgU0lQLSBv ciBTSVBTLVVSSQ0KPiA+ID4gYXBwbGllcyBhbHNvIHRvIFBSRVMtVVJJcy4NCj4gPiA+DQo+ID4g PiAzLiBBbHNvIHRoZXJlIGlzIG5vdGhpbmcgdG8gc2F5IHdoYXQgdG8gZG8gaWYgdGhlIFBSRVMg VVJJDQo+ID4gPiBmYWlscyB0byByZXNvbHZlIHRvIGEgU0lQIG9yIFNJUFMgVVJJLg0KPiA+ID4N Cj4gPiA+IDQuIFRoZSAiTVVTVCBiZSBhIFNJUC0sIFNJUFMtIG9yIFBSRVMtVVJJIiB0ZXh0IGlu IGNpdGVkDQo+ID4gPiBhYm92ZSBzZWVtcyB0byBwcmVjbHVkZSB0aGUgYWRkaXRpb24gb2YgZnV0 dXJlIFVSSSBzY2hlbWVzLA0KPiA+ID4gd2hpY2ggc2VlbXMgdG8gYmUgaW4gY29uZmxpY3Qgd2l0 aCA4LjYgKHJlZ2lzdHJ5DQo+ID4gPiBlc3RhYmxpc2htZW50IGZvciBsb2NhdGlvbiBVUklzKS4N Cj4gPiA+DQo+ID4gPg0KPiA+ID4gSm9obg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+ID4g PiBzaXBjb3JlQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcGNvcmUNCj4gPiA+DQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cg== From root@core3.amsl.com Tue Aug 17 16:45:06 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D7FDA3A680A; Tue, 17 Aug 2010 16:45:05 -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: <20100817234505.D7FDA3A680A@core3.amsl.com> Date: Tue, 17 Aug 2010 16:45:05 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-rfc3265bis-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: Tue, 17 Aug 2010 23:45:06 -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 : SIP-Specific Event Notification Author(s) : A. Roach Filename : draft-ietf-sipcore-rfc3265bis-02.txt Pages : 50 Date : 2010-08-17 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-02.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-rfc3265bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-17164015.I-D@ietf.org> --NextPart-- From adam@nostrum.com Wed Aug 18 14:31:23 2010 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 A9DAA3A6A08 for ; Wed, 18 Aug 2010 14:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, SPF_PASS=-0.001, 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 glh7kEqQaEFh for ; Wed, 18 Aug 2010 14:31:18 -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 8F8F23A6949 for ; Wed, 18 Aug 2010 14:31:17 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o7ILVpii024514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Aug 2010 16:31:52 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C6C5147.7090304@nostrum.com> Date: Wed, 18 Aug 2010 16:31:51 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" 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] 3265bis-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: Wed, 18 Aug 2010 21:31:23 -0000 [as an individual] I have issued a new version of RFC3265bis, reflecting the changes discussed in Stockholm and Anaheim. This version closes all the formal open issues (although it has recently come to my attention that the document still needs to be updated to reflect the IANA registration policies detailed by sipchange). New version: http://www.ietf.org/id/draft-ietf-sipcore-rfc3265bis-02.txt Diffs from -01: http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc3265bis-02.txt /a From pkyzivat@cisco.com Thu Aug 19 08:54:56 2010 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 0C4763A695D for ; Thu, 19 Aug 2010 08:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 5yaTOxEyiyLi for ; Thu, 19 Aug 2010 08:54:55 -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 E959E3A659B for ; Thu, 19 Aug 2010 08:54:54 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE/wbExAZnwM/2dsb2JhbACgUHGiD5t+hTcEiXE X-IronPort-AV: E=Sophos;i="4.56,233,1280707200"; d="scan'208";a="149535414" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Aug 2010 15:55:29 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7JFtTN6020102; Thu, 19 Aug 2010 15:55:29 GMT Message-ID: <4C6D53F1.5020409@cisco.com> Date: Thu, 19 Aug 2010 11:55:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <4C6C5147.7090304@nostrum.com> In-Reply-To: <4C6C5147.7090304@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] 3265bis-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: Thu, 19 Aug 2010 15:54:56 -0000 [as individual] I have a couple of comments about this version: First, I question some changes you made to the state model picture in 4.1.2. Now Timer N expiry is a trigger for moving to Terminated from Pending or Active. How can that be right? I think this would be right if it referenced the (unnamed) timer set from the expires value in the most recently received notify. Second, section 8.2 is now entirely empty since the table 2/3 info was removed. Section 8.1 was similar, but now has a few words describing its new methods. Perhaps this section should have a few words about the new headers. Or else it can just be removed entirely. Thanks, Paul From HKaplan@acmepacket.com Thu Aug 19 13:21:48 2010 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 2B6133A67AC for ; Thu, 19 Aug 2010 13:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_47=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 VWefaCH2pRbr for ; Thu, 19 Aug 2010 13:21:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 101F23A6895 for ; Thu, 19 Aug 2010 13:21:46 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 19 Aug 2010 16:22:20 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 19 Aug 2010 16:22:00 -0400 From: Hadriel Kaplan To: "sipcore@ietf.org" Date: Thu, 19 Aug 2010 16:21:58 -0400 Thread-Topic: Comments on draft-ietf-sipcore-keep-05 Thread-Index: Acs/3Cyfefv2XMp4S+6a17CBnpJFJA== Message-ID: <430FC6BDED356B4C8498F634416644A926943819D1@mail> 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 Subject: [sipcore] Comments on draft-ietf-sipcore-keep-05 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, 19 Aug 2010 20:21:48 -0000 Howdy, I think it's getting close to final. Below are my comments... Technical: 1) What happens if the two nodes indicate keepalives, but the downstream do= esn't receive them? In Outbound, it would cause a flow failure for the reg= istration. My guess is vendors will do the same for draft-keep. (probably = even for dialog-based keepalives) So to me that means (a) the indicated ti= mer value is a maximum time which the sender must send them in, not just a = "recommendation", and (b) failure to receive a response to the keepalive sh= ould trigger a re-Register, which needs to be indicated in text in the draf= t. 2) Just to be clear, even if there are multiple Registrations or dialogs on= a given connection, only one keepalive "instance" would be active on that = connection, right? I.e., we're not talking about sending multiple keepaliv= es, one per dialog/registration, on the same connection. So something like= this should be added to section 4.1: "Even though the keepalive negotiation is performed on a registration or di= alog basis, the keepalive mechanism is per transport connection, meaning on= ly one keepalive is sent from the upstream to the downstream entity per TCP= connection or UDP port pairs, even if there are multiple dialogs and regis= trations across them. Since keepalive is negotiated in each REGISTER or di= alog transaction, the most recently negotiated settings MUST be used for th= e whole connection." There is, unfortunately, a complication around this stuff: a proxy can be s= tateful for some calls and stateless for others. This means you can send a= INVITE request downstream and be told to do keepalives, while your next IN= VITE to it does not, but you still need to do keepalives. I'm not sure how= to handle this in text. 3) Section 4.2.2 says: Usage of keep-alives can be negotiated when the registration is established, or later during the lifetime of the registration. I don't believe it's technically possible to re-negotiate it during the lif= etime, because the "lifetime" is the expiry value of the Registration. Onc= e you send another REGISTER to renegotiate it, it's a new "lifetime". No? = =20 4) Section 4.3 has: A SIP entity that has negotiated sending of keep-alives associated with a registration MUST be prepared to receive, from the receiver of the keep-alives, SIP messages (requests and responses) associated with the registration on the same IP port:address from where the keep-alives are sent. If the SIP entity sends the keep-alives over a connection-oriented transport protocol, it MUST be prepared to receive SIP messages associated with the registration over the same connection. The same rules apply for SIP messages associated with a dialog, if the SIP entity has negotiated sending of keep-alives associated with a dialog. Why is that in this draft?? (I don't understand how it relates) 5) Security considerations. There are some security considerations which a= re not in 5626. Just off the top of my head they are: a) Any downstream SIP entity, beyond the adjacent downstream peer node, can= modify the Via header identifying the local node and thus cause the local = node to send keepalives to its adjacent peer (at high rates) if the peer do= es not support this keepalive mechanism. b) A man-in-the-middle between two SIP nodes can modify the Via header at w= ill, and thus can prevent keepalive from being used, or can decrease the ti= mer value to a very low value to consume resources, or can cause the downst= ream to expect keepalives while the upstream does not know to send them and= thus cause a failure. Editorial: - s/CRLF/double-CRLF/g - Section 4.4 first para, change: The SIP entity must support those aspects of STUN that are required in order to apply the STUN keep-alive mechanism defined in [RFC5626], and it must support the CRLF keep-alive mechanism defined in [RFC5626]. To: The SIP entity must support those aspects of STUN that are required in order to apply the STUN keep-alive mechanism defined in [RFC5626] for connection-less transports such as UDP, and it must support the CRLF keep-alive=20 mechanism defined in [RFC5626] for connection-oriented transports=20 such as TCP and TLS over TCP. -hadriel From adam@nostrum.com Thu Aug 19 15:04:55 2010 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 582293A6991 for ; Thu, 19 Aug 2010 15:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, SPF_PASS=-0.001, 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 jYwRNeM9eBy5 for ; Thu, 19 Aug 2010 15:04:54 -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 258883A6899 for ; Thu, 19 Aug 2010 15:04:53 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o7JM5RIx014977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 17:05:27 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C6DAAA7.8080507@nostrum.com> Date: Thu, 19 Aug 2010 17:05:27 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Paul Kyzivat References: <4C6C5147.7090304@nostrum.com> <4C6D53F1.5020409@cisco.com> In-Reply-To: <4C6D53F1.5020409@cisco.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 \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] 3265bis-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: Thu, 19 Aug 2010 22:04:55 -0000 [as individual] On 8/19/10 10:55 AM, Paul Kyzivat wrote: > First, I question some changes you made to the state model picture in > 4.1.2. Now Timer N expiry is a trigger for moving to Terminated from > Pending or Active. How can that be right? This is part of the change to make Timer N apply to subscription refreshes. When a subscription is in Active (and even Pending, if permission pends for longer than a refresh period), the subscriber periodically sends new SUBSCRIBE messages to refresh the expiration. The document *now* says that these refreshes cause Timer N to be set. If no NOTIFY arrives before Timer N expires, then the subscription will transition from Active (or Pending) to Terminated. > Second, section 8.2 is now entirely empty since the table 2/3 info was > removed. Right. With this change, section 8.2 simply serves as a top-level container for sections 8.2.1, 8.2.2, and 8.2.3. This is the same as is done for sections 3, 4, 4.1, 4.2, 4.4, 6, 7, 8.3, and 9. /a From pkyzivat@cisco.com Thu Aug 19 16:33:27 2010 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 6B7853A691D for ; Thu, 19 Aug 2010 16:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.482 X-Spam-Level: X-Spam-Status: No, score=-110.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 p8VWhK5S58Jw for ; Thu, 19 Aug 2010 16:33:24 -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 97DF13A691A for ; Thu, 19 Aug 2010 16:33:24 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM9bbUxAZnwM/2dsb2JhbACgU3GkVJtshTcEiXE X-IronPort-AV: E=Sophos;i="4.56,236,1280707200"; d="scan'208";a="149680201" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Aug 2010 23:33:59 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7JNXxHG014394; Thu, 19 Aug 2010 23:33:59 GMT Message-ID: <4C6DBF67.5000401@cisco.com> Date: Thu, 19 Aug 2010 19:33:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <4C6C5147.7090304@nostrum.com> <4C6D53F1.5020409@cisco.com> <4C6DAAA7.8080507@nostrum.com> In-Reply-To: <4C6DAAA7.8080507@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] 3265bis-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: Thu, 19 Aug 2010 23:33:28 -0000 Adam Roach wrote: > > [as individual] > > On 8/19/10 10:55 AM, Paul Kyzivat wrote: >> First, I question some changes you made to the state model picture in >> 4.1.2. Now Timer N expiry is a trigger for moving to Terminated from >> Pending or Active. How can that be right? > > This is part of the change to make Timer N apply to subscription > refreshes. When a subscription is in Active (and even Pending, if > permission pends for longer than a refresh period), the subscriber > periodically sends new SUBSCRIBE messages to refresh the expiration. The > document *now* says that these refreshes cause Timer N to be set. If no > NOTIFY arrives before Timer N expires, then the subscription will > transition from Active (or Pending) to Terminated. I understand how Timer N should apply after sending a resubscribe. But that is not how I read the diagram. The diagram says to me that the following is a common scenario: - I send an initial subscribe and enter notify-wait - I receive a NOTIFY with pending, and enter pending. - If I don't get another notify within Timer N, I enter terminated state. - To avoid that fate, before Timer N expires I can send a resubscribe, thus resetting Timer N and (I guess) going back into notify-wait. If I send a subscribe that goes into pending, it could be hours or days until the notifier's user gets around to blessing me. The above analysis says that for all that time I'll be sending a new resubscribe every Timer N seconds. That doesn't seem desirable. IIUC, the intended behavior is that when in pending or active, one is waiting for the *expires* timer to run down. (It of course gets updated with each notify received.) When it runs down enough, a new subscribe should be sent, and then timer N is set again for the first notify after that. But I don't get that behavior out of the existing diagram. One way to show that would be: From pending and active, - sending a resubscribe causes transition back to notify-wait. - exhaustion of the expires timer causes transition to terminated. >> Second, section 8.2 is now entirely empty since the table 2/3 info was >> removed. > > Right. With this change, section 8.2 simply serves as a top-level > container for sections 8.2.1, 8.2.2, and 8.2.3. > > This is the same as is done for sections 3, 4, 4.1, 4.2, 4.4, 6, 7, 8.3, > and 9. ok. Thanks, Paul From john.elwell@siemens-enterprise.com Mon Aug 23 01:29:44 2010 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 823B13A69AC for ; Mon, 23 Aug 2010 01:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.748 X-Spam-Level: X-Spam-Status: No, score=-102.748 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, 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 bDLXCu2f6Tt7 for ; Mon, 23 Aug 2010 01:29:43 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3929E3A67CC for ; Mon, 23 Aug 2010 01:29:42 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1247442; Mon, 23 Aug 2010 10:30:12 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id E0BAB1EB82B5; Mon, 23 Aug 2010 10:30:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 23 Aug 2010 10:30:12 +0200 From: "Elwell, John" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Winterbottom, James" , "sipcore@ietf.org" Date: Mon, 23 Aug 2010 10:30:11 +0200 Thread-Topic: [sipcore] Questions on location conveyance and dereferencing Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYwAAUJuAAABop6EAAHVqQAAAoHrwAAE+BsAAAt1BgAAt+KYAAcGj2aA= Message-ID: References: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.com>, <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AC@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BE56@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B4502E9BEBD@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B4502E9C319@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E9C319@FIESEXC015.nsn-intra.net> 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 Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 23 Aug 2010 08:29:44 -0000 =20 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo)=20 > [mailto:hannes.tschofenig@nsn.com]=20 > Sent: 16 August 2010 07:27 > To: Elwell, John; ext Winterbottom, James; sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and=20 > dereferencing >=20 > Hi John,=20 > =20 >=20 > > > In your enterprise LIS for emergency services you will most=20 > > > likely want > > > to figure out who is going to consume that reference. Quite=20 > > likely the > > > PSAP will consume the reference. If so, you better talk=20 > to the PSAP > > > responsible for that specific area.=20 > > [JRE] Quite so, except is it likely my VoIP service provider=20 > > might also want to inspect the location, to confirm correct=20 > > routing? Then depending on which SP I choose to route that=20 > > particular call through, they might support different URI=20 > > schemes? It seems to be a mess not having a MUST implement scheme. >=20 > I understand the theoretical concern.=20 > I have no objections against a mandatory to implement HTTP-based > dereferencing mechanism.=20 >=20 >=20 > > > XMPP does not provide equivalent functionality of SIP location > > > conveyance.=20 > > > So, another non-issue.=20 > > [JRE] That was not the point I was making. I was simply=20 > > saying that even applications that support presence might=20 > > support XMPP rather than SIMPLE, and therefore would not want=20 > > to implement RFC 3856. Instead they might prefer to use HTTP. > I am not quite sure which scenario you have in mind.=20 > If I have an end host that supports XMPP and then gets a location URI > then there is the question of who is going to dereference it. If it is > the end point then it would have to implement the protocol=20 > indicated by > the URI scheme. Now, if this happens to be SIP then this end=20 > point would > have to implement SIP. The end host could, however, request=20 > location by > value instead instead of going through the dance of utilizing a LbyR.=20 [JRE] So how does it request LbyV? John > If the end point does not dereference the LbyR but instead some other > entity then there is the question of how this reference then actually > gets there.=20 >=20 > Ciao > Hannes > = From Hannes.Tschofenig@gmx.net Mon Aug 23 01:38:39 2010 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 D186C3A684C for ; Mon, 23 Aug 2010 01:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.298 X-Spam-Level: X-Spam-Status: No, score=-101.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 Nr+DxO5S0i+h for ; Mon, 23 Aug 2010 01:38:38 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id E742D3A67CC for ; Mon, 23 Aug 2010 01:38:37 -0700 (PDT) Received: (qmail 4589 invoked by uid 0); 23 Aug 2010 08:39:10 -0000 Received: from 192.100.112.211 by rms-de002.v300.gmx.net with HTTP Content-Type: multipart/alternative; boundary="========GMXBoundary226861282552748911270" Date: Mon, 23 Aug 2010 10:38:26 +0200 From: "Hannes Tschofenig" Message-ID: <20100823083908.226860@gmx.net> MIME-Version: 1.0 To: "Elwell, John" ,"Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Winterbottom, James" ,sipcore@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 X-GMX-UID: zVoHf6ptODB6UpkCsWVMI189Ji9SWlL+ X-FuHaFi: 0.55000000000000004,0.55000000000000004 Subject: Re: [sipcore] Questions on location conveyance and dereferencing 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, 23 Aug 2010 08:38:39 -0000 --========GMXBoundary226861282552748911270 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I would use the following HELD request: geodetic civic Ciao Hannes ----- Ursprüngliche Nachricht ----- Von: Elwell, John Gesendet: 23.08.10 11:30 Uhr An: Tschofenig, Hannes (NSN - FI/Espoo), ext Winterbottom, James, sipcore@ietf.org Betreff: Re: [sipcore] Questions on location conveyance and dereferencing > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: 16 August 2010 07:27 > To: Elwell, John; ext Winterbottom, James; sipcore@ietf.org > Subject: RE: [sipcore] Questions on location conveyance and > dereferencing > > Hi John, > > > > > In your enterprise LIS for emergency services you will most > > > likely want > > > to figure out who is going to consume that reference. Quite > > likely the > > > PSAP will consume the reference. If so, you better talk > to the PSAP > > > responsible for that specific area. > > [JRE] Quite so, except is it likely my VoIP service provider > > might also want to inspect the location, to confirm correct > > routing? Then depending on which SP I choose to route that > > particular call through, they might support different URI > > schemes? It seems to be a mess not having a MUST implement scheme. > > I understand the theoretical concern. > I have no objections against a mandatory t o implement HTTP-based > dereferencing mechanism. > > > > > XMPP does not provide equivalent functionality of SIP location > > > conveyance. > > > So, another non-issue. > > [JRE] That was not the point I was making. I was simply > > saying that even applications that support presence might > > support XMPP rather than SIMPLE, and therefore would not want > > to implement RFC 3856. Instead they might prefer to use HTTP. > I am not quite sure which scenario you have in mind. > If I have an end host that supports XMPP and then gets a location URI > then there is the question of who is going to dereference it. If it is > the end point then it would have to implement the protocol > indicated by > the URI scheme. Now, if this happens to be SIP then this end > point would > have to implement SIP. The end host could, however, request > location by > value instead instead of going through the dance of utilizing a LbyR. [JRE] So how does it request LbyV? John > If the end point does not dereference the LbyR but instead some other > entity then there is the question of how this reference then actually > gets there. > > Ciao > Hannes > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --========GMXBoundary226861282552748911270 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable