From internet-drafts@ietf.org Thu Aug 2 02:48:26 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F03721F8E45; Thu, 2 Aug 2012 02:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0tVcZZpV6Mt; Thu, 2 Aug 2012 02:48:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB7E21F8E43; Thu, 2 Aug 2012 02:48:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120802094825.27637.79622.idtracker@ietfa.amsl.com> Date: Thu, 02 Aug 2012 02:48:25 -0700 Cc: bliss@ietf.org Subject: [BLISS] I-D Action: draft-ietf-bliss-call-completion-15.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 09:48:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Basic Level of Interoperability for SIP S= ervices Working Group of the IETF. Title : Call Completion for Session Initiation Protocol (SIP) Author(s) : Dale R. Worley Martin Huelsemann Roland Jesske Denis Alexeitsev Filename : draft-ietf-bliss-call-completion-15.txt Pages : 35 Date : 2012-08-02 Abstract: The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'automatic redial' in the SIP Service Examples (RFC 5359). For the realization of a more comprehensive solution with queuing , this document introduces an architecture for implementing these features in the Session Initiation Protocol where "Call completion" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for call completion into a queue at the callee's endpoint, and when a caller's request is ready to be serviced, re-attempt of the original, failed call is made. The architecture is designed to interoperate well with existing call- completion solutions in other networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bliss-call-completion There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bliss-call-completion-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bliss-call-completion-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Martin.Huelsemann@telekom.de Thu Aug 2 04:29:35 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B41421F8DA4 for ; Thu, 2 Aug 2012 04:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RenPwJ8vpagt for ; Thu, 2 Aug 2012 04:29:34 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 110C421F8DA6 for ; Thu, 2 Aug 2012 04:29:33 -0700 (PDT) Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 02 Aug 2012 13:29:01 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.163]) by HE111296.EMEA1.CDS.T-INTERNAL.COM ([fe80::19ac:3fb4:a382:6df4%16]) with mapi; Thu, 2 Aug 2012 13:29:01 +0200 From: To: Date: Thu, 2 Aug 2012 13:29:00 +0200 Thread-Topic: [BLISS] I-D Action: draft-ietf-bliss-call-completion-15.txt Thread-Index: Ac1wlAMl7ERzTdx2ThiGgHpMWI8VigACbI5g Message-ID: <9762ACF04FA26B4388476841256BDE020115FF999CA9@HE111543.emea1.cds.t-internal.com> References: <20120802094825.27637.79622.idtracker@ietfa.amsl.com> In-Reply-To: <20120802094825.27637.79622.idtracker@ietfa.amsl.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BLISS] I-D Action: draft-ietf-bliss-call-completion-15.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 11:29:35 -0000 Dear colleagues, a new version of the call-completion draft has been uploaded. There are no technical changes, but we've tried to clarify a lot of things,= based on the questions that came up at the AD review. Please check of all = the points have been addressed: http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf-bl= iss-call-completion-14.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-bliss= -call-completion-15.txt I think one of the most important clarifications was that in context of sus= pend/resume procedures PUBLISH is used in accordance with RFC 3903, an exam= ple has been added. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] > Im Auftrag von internet-drafts@ietf.org > Gesendet: Donnerstag, 2. August 2012 11:48 > An: i-d-announce@ietf.org > Cc: bliss@ietf.org > Betreff: [BLISS] I-D Action: draft-ietf-bliss-call-completion-15.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Basic Level of > Interoperability for SIP Services Working Group of the IETF. > > Title : Call Completion for Session > Initiation Protocol (SIP) > Author(s) : Dale R. Worley > Martin Huelsemann > Roland Jesske > Denis Alexeitsev > Filename : draft-ietf-bliss-call-completion-15.txt > Pages : 35 > Date : 2012-08-02 > > Abstract: > The call completion feature defined in this specification > allows the > caller of a failed call to be notified when the callee becomes > available to receive a call. > > For the realization of a basic solution without queuing, this > document references the usage of the dialog event package > (RFC 4235) > that is described as 'automatic redial' in the SIP Service Examples > (RFC 5359). > > For the realization of a more comprehensive solution with queuing , > this document introduces an architecture for implementing these > features in the Session Initiation Protocol where "Call completion" > implementations associated with the caller's and callee's endpoints > cooperate to place the caller's request for call completion into a > queue at the callee's endpoint, and when a caller's > request is ready > to be serviced, re-attempt of the original, failed call is made. > > The architecture is designed to interoperate well with > existing call- > completion solutions in other networks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bliss-call-completion > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bliss-call-completion-15 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bliss-call-completion-15 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss > From rjsparks@nostrum.com Thu Aug 9 11:27:14 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C867421F86BA for ; Thu, 9 Aug 2012 11:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZ2UEHgLwF2S for ; Thu, 9 Aug 2012 11:27:13 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 87A4B21F86B3 for ; Thu, 9 Aug 2012 11:27:12 -0700 (PDT) Received: from unnumerable.local (pool-173-57-102-202.dllstx.fios.verizon.net [173.57.102.202]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q79IR14v093364 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 13:27:02 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <502400F5.1090800@nostrum.com> Date: Thu, 09 Aug 2012 13:27:01 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Martin.Huelsemann@telekom.de References: <4F10B30A.9060203@nostrum.com> <9762ACF04FA26B4388476841256BDE020115C8FA18DA@HE111543.emea1.cds.t-internal.com> <4F43BA45.9090606@nostrum.com> In-Reply-To: <4F43BA45.9090606@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 173.57.102.202 is authenticated by a trusted mechanism) Cc: draft-ietf-bliss-call-completion@tools.ietf.org, bliss@ietf.org, alexeitsev@teleflash.com Subject: Re: [BLISS] AD review: draft-ietf-bliss-call-completion-14 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:27:14 -0000 Martin - I haven't see a response to this message, and the updates in -15 do not address the issues called out here with the use of PUBLISH as you currently specify. Could you please reply to those sections below? RjS On 2/21/12 9:37 AM, Robert Sparks wrote: > Thanks Martin - more comments inline. > > Will you be at the Paris IETF meeting? > > On 2/17/12 10:41 AM, Martin.Huelsemann@telekom.de wrote: >> Hi Robert, >> >> thank you very much for the detailed review. >> >> We will provide a new version considering your comments. >> >> Please find already some answers inside. >> >> >> Best regards, Martin >> >> >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] >>> Im Auftrag von Robert Sparks >>> Gesendet: Freitag, 13. Januar 2012 23:41 >>> An: bliss@ietf.org; draft-ietf-bliss-call-completion@tools.ietf.org >>> Betreff: [BLISS] AD review: draft-ietf-bliss-call-completion-14 >>> >>> Summary: This document has issues that need to be addressed >>> before progressing to IETF Last Call. >>> >>> This document was very difficult to review. Please call out >>> anyone who provided a substantive review in the document >>> quality section of an updated shepherd writeup - they deserve >>> the acknowledgement! >>> >>> I think there might be places where the structure of the >>> document became stressed as the design changed over time. >>> Please consider an editorial pass focusing on organizing the >>> resulting implementation requirements in ways that are easier >>> to reference. >>> >>> Major issues >>> >>> - The document's proposed use of PUBLISH is not consistent with the >>> semantics of that method. It attempts to use PUBLISH to affect >>> the subscription state, not the state of the event being >>> subscribed to (it's telling that PUBLISHing to this event package >>> doesn't allow setting the state being subscribed to). Among other >>> things, this prevents separating the state agent from the state >>> authority. >> The concept is the following: The caller sends it's own status >> information in the PUBLISH request. In this case there is no change >> in the CC monitor (the queue) state done by the PUBLISH request >> directly, but either an indirect change of the state based on the >> information about the caller status. The CC monitor acts as a state >> composer, composing the state of the queue from the states of the >> different callers. > This isn't composition. It's conflation of unrelated things. You have > an application that's operating on two unrelated sources of > information. If you really want to use sip events to carry the > information about the caller, > you should be considering a separate event package for it. If that > feels wrong, it's another sign that PUBLISH is > not the hammer you're looking for to pound on this particular nail. > > Speaking more generally to the events architecture, an element that > has enough information to act as a publisher necessarily has the > information it needs to be able to serve subscriptions directly. It is > choosing to publish to a state agent to deal with matters outside of > the contents of the package itself (not always being connected, having > limited bandwidth, etc.). Even in an idealized presence system where > the ultimate presence document is composed from many contributing > publishers, the individual sources have enough information (and it > makes sense within the definition of the package) to accept > subscriptions to their part of the total state. Further, > subscribing to presence.winfo at the state agent will provide > meaningful data to each of the contributing sources. > >> >> >> >> >>> The document modifies how PUBLISH identifies the >>> resource being manipulated by looking at the From URI and not >>> only at the Request-URI. How the Callee's agent responds to the >>> request to change this subscription state is underspecified - >>> when can it reject a request? What is the caller supposed to do >>> if the request fails? >> As mentioned the PUBLISH is not a RPC, the CC agent on behalf of the >> callee publishes information about the reachability of the callee for >> CC recalls. The monitor composes the state. This state can be used to >> evaluate if it is useful to start a CC recall or not. > I think you were still trying to respond to the first point above here. > This is a different question, and will stand independent of what > technique you use to make > the request to change the information about the caller. What happens > when that request needs > to fail (due to parsing, overload, authorization, application-specific > logic, or any of the other reasons > UAS have to reject requests)? >> >> >> >>> - As written, the first paragraph of section 9.7 asks this package >>> to violate the basic mechanics of RFC3265. It is a violation of >>> the architecture to completely ignore the the expiration time >>> value requested in an initial or refresh SUBSCRIBE request. The >>> responder may choose an expiration time less than or equal to the >>> value there. It may not choose a longer expiration time for the >>> subscription. >> Yes this is unclear, what is meant is that the duration in the >> exoires answer shall not exceed the remaining CC timer. >> >> >>> - There is some important conversation missing from the security >>> considerations section. >>> >>> - The dialog event package requires authentication, and digest >>> authentication is mandatory to implement. This package >>> doesn't appear to require any authentication other than >>> presenting a (possibly well known) URI. More discussion of >>> the policy for accepting subscriptions is needed to allow >>> implementers to protect the privacy of the callee. Otherwise, >>> it becomes trivial to use this package to obtain, for >>> instance, information about the callee's phone usage. >>> Similarly, the presence event package has a rich >>> authorization model, and discusses the security (particularly >>> privacy) implications of having the authorization settings >>> too open. >> >>> - As written, there does not appear to be any protection >>> against an attacker causing everyone else that might be in a >>> queue to be marked not-available, ensuring his call moves to >>> the front of the queue. He only needs to know the AoRs of the >>> callers he might be competing with and send PUBLISH requests >>> with those AoRs in the From header field. >>> - What keeps a new caller from just adding the m= attribute to >>> a new INVITE in order to get the preferential treatment by >>> the network and the callee's UA described in several sections >>> of the document? Was an approach that used a temp-GRUU >>> considered instead? It would not have the property of being >>> as easy to guess as adding an m= URI parameter to an AoR. >> As for many mechanisms in the CC draft also here we had to consider >> the interworking to the PSTN. There we have only a very basic CC >> prioritization indicator in the IAM, saying not much more than 'this >> IAM is prioritized for CC'. That's why the callee's monitor MUST >> record the From URI from the initial call, to have the chance to >> check it against incoming INVITEs and verify id this INV is in fact >> for CC. Clarifying text for this is needed in the draft. > That clarifying text needs to capture the scenarios above, and answer > the questions. For instance, if there is nothing to keep an attacker > from marking everyone else in the queue as not available, the document > needs to call that out as a security consideration. (I hope this isn't > what the group plans to end with). >> >>> - A malicious callee could return several (many) NOTIFYs with >>> different to-tags, each containing a different cc-URI, >>> leading the caller to parallel-fork a large number of >>> subscriptions to a victim. >>> Some questions >>> >>> - Section 9.10 calls out that subscribers need to be prepared to >>> get NOTIFYs from multiple places due to forks in the SUBSCRIBE, >>> but nothing in the document explores how this affects the >>> call-completion application. What keeps the following scenario >>> from occurring: Adam tries to call me, but I'm busy (on my desk >>> phone). He subscribes for call completion, and the subscribe gets >>> forked to both my desk and home phone. My home phone is not busy, >>> so it sends a NOTIFY with "ready" right away. Adam's phone calls >>> my home phone. >> To avoid this situation Adam should add the 'm' (mode) URI parameter, >> in this case set to 'BS' (busy subscriber). In this case a CC recall >> is triggered twhen a busy condition at a callee UA has ended. Of >> course this situation also depends a littlebit on the forking proxy, >> does it for the initial INVITE send back the 180 from your home phone >> (indication CC possible 'NR') and also the 486 (indication CC >> possible 'BS')? Clarifying text is needed. >> >> >>> - What keeps this from happening? Adam calls and I reject his call >>> because I'm waiting for another (I press X and the phone just >>> reports that I'm busy). Adam's phone subscribes for >>> call-completion and gets a NOTIFY of "ready" - his phone calls >>> mine again, forcing me to re-reject him. This repeats until I >>> take my phone off the hook (or engage a global DND) causing me to >>> not be able to receive the call I was waiting for. >> If the callee's monitor does not want to enable the caller to make >> use of the CC service, it will not insert a Call-Info header field >> with "purpose=call-completion" in the final response message. > Where is the text in the document that defines that behavior? >> Of course Adam's phone could try to sunscribe for CC at your phone, >> but in this case your phone simply rejects the subscription, which >> should not affect your reachability for the call you are waiting for. > Similarly, where in the text is this made clear? It is separable from > the the scenario above - Adam could write a script to subscribe to > every address at an enterprise. What normative text causes all those > subscriptions to be rejected? >> >> >>> - Would a callee ever want to subscribe to call-completion.winfo to >>> see who's in his queue? Will the current design prevent >>> implementing a server for call-completion.winfo? >> Actually we never discussed this option. We will check it. >> >> >>> Remaining issues (mostly in document order) >>> >>> - application/call-completion needs to be sent to type review. >>> - It would be useful to more carefully describe exactly what the >>> resource being subscribed to. >>> - Please call out how this document updated 3261 in the >>> introduction. >>> - Section 4.2 paragraph 1: Is 100rel required? recommended? >>> - It's not easy to understand from the text why the subscribing UA >>> is attempting to subscribe to multiple URIs (the first occurrence >>> is in 4.2 paragraph 4). Some additional motivating text would >>> help. >>> - The document mischaracterizes 'merged' requests as being those >>> that share the same Call-ID. As Section 8.2.2.2 of RFC3261 >>> defines, it's more than that - the things that have to be the >>> same are the From tag, Call-Id, and CSeq. This occurs several >>> places in the document: 6.2 second paragraph, description of >>> example in section 8, 9.7 third paragraph. It's worth noting that >>> the UA core in 8.2.2.2 does this merge detection - you are >>> restating a requirement, not adding one - you should probably >>> just note that the UA will behave as required by that section of >>> RFC3261. >>> - It's worth explicitly calling out (at least in section 6.2) that >>> you are expecting the subscribing UA to fork its own requests (so >>> that the merge behavior you are describing can take place). This >>> means keeping more than the Call-Id constant. An implementer will >>> have to select or develop a SIP implementation that allows them >>> to do that. >>> - There needs to be additional clarity to the specification of the >>> use of the service-retention indication. What is the caller's >>> (the subscriber's) endpoint supposed to do differently when it >>> sees the service-retention option arrive in a NOTIFY? The >>> difference in the behavior of the callee's system is hard to >>> extract - the most salient description is the last paragraph of >>> 4.2. >>> - Section 6.2 first paragraph: m parameter of a SUBSCRIBE SHOULD >>> match the m parameter passed through the Call-Info header. Why is >>> this not MUST? >> Again because of the PSTN interworking, on TCAP there isn't an >> equivalent for all the m-parameter values. >> >> I see there are more questions why there is SHOULD and not MUST. I >> still have to check them in particular. But as i said, most of the >> softening in the draft is due to enable an interworking with the PSTN >> CC service. For the latter more information can be found in ETSI ETS >> 300 356-18 and ITU-T Q.733. > Please watch for opportunities to make this clear in the text. >>> - Why does the document specify a request-disposition of no-cancel >>> for SUBSCRIBE requests? An intermediary cannot send a CANCEL to >>> forked legs of a SUBSCRIBE request in the first place. >> >>> - In section 6.2 paragraph 4, you mean to say the caller's agent >>> must be prepared to receive multiple NOTIFYs establishing >>> different dialogs for each initial SUBSCRIBE request it sends. It >>> is not possible for the agent to receive multiple (final) >>> responses to the SUBSCRIBE request itself. >> >>> - The string 'cc-state' appears for the first time in section 6.3 >>> with no context. The discussion of state before that in the >>> document is a superset of the states represented with cc-state. >>> Please at least provide a forward pointer. It would be better to >>> explicitly describe what cc-state is before you get to this >>> section. >> >>> - The first sentence in section 6.3 is hard to parse. Could it be >>> broken into more than one sentence? Why are the SHOULDs in this >>> section not MUSTs? >> >>> - In section 7.1, why is the callee's monitor required to send at >>> least one non-100 provisional (with a Call-Info in it)? Is it >>> because the final response might not be delivered to the calling >>> endpoint due to forking. If so, don't you need to require 100rel? >> >>> - Why is the SHOULD in 7.1 paragraph 3 not a MUST? >> >>> - Why does 7.1 paragraph 4 start "When applicable,"? >> Means simply 'if CC is offered'. >> >>> - In this version of the document, the last paragraph of 7.1 is the >>> only definition of the possible values for the m= URI parameter. >>> It would help to list them with the definition of the parameter >>> itself. >>> - The requirements around forking in section 7.2 paragraph 2 belong >>> in section 9. Why is the requirement to respond with a 482 to all >>> but one fork a SHOULD and not a MUST? >> >>> - Why is the SHOULD in 7.3 paragraph 2 not a MUST? >> >>> - Subsections of Section 7 use SHALL instead of MUST - it would be >>> better to be consistent throughout the document. >>> - In 7.4 paragraph one, where you say "if the CC call fails", it >>> would be better to say "if the CC call is not accepted". The call >>> could fail without the callee's monitor seeing any of the >>> signalling. >>> - In 7.4 paragraph 1, last sentence, in what circumstance would the >>> callee's monitor NOT terminate the relevant subscription? >> I think this SHOULD should or better must be a MUST. >> >>> - 7.4 paragraph 2 (which assumes the UA can only handle one call at >>> a time) should be made consistent with 7.3 paragraph 3 (which >>> allows UAs that can support multiple calls) >>> - 7.6 paragraph 1 says "SHALL process the queue as described in >>> subclause 7.3". But 7.3 does not talk about processing queues. >> >>> - In the example, you show a 487 to the invite and motivate it by >>> some proxy having generated a CANCEL. That proxy would have >>> received a 487, but assuming it got no better responses from any >>> other leg, it would most likely send a 480. If there weren't >>> intervening proxies, the response might be one of several >>> 400-class responses (perhaps a 408). Please call out that there >>> may be many variations in this failure response. >> >>> - Proxies will not aggregate Call-Info header fields from multiple >>> final responses into the response they send upstream. In a >>> general deployment, the only time you will see that the callee >>> supports call-completion (at least given how the capability is >>> signaled in this document) is if it's final response is chosen as >>> "best" by every proxy in the chain. It's worth pointing out that >>> some 4xx responses from the callee's UA are more likely to be >>> chosen as "best" than others. It's also probably worth pointing >>> out that in in situations like you allude to in the example in >>> section 8, when proxies cancel legs, the 487 they stimulate from >>> the callee's UAs are not likely to be chosen as "best". >> Text for forking proxies need, s.a. >> >> >>> - The third paragraph of section 9.4 is very unclear. I can't parse >>> the first sentence at all. In the second sentence, it might be >>> clearer to say "can never" instead of "cannot" (assuming my guess >>> at what the paragraph is trying to say is correct). The third >>> sentence doesn't make sense, and I wonder if the text matched a >>> previous design better? Moving between available and >>> not-available (using PUBLISH) doesn't affect the subscription >>> duration - what is the sentence trying to talk about when it >>> mentions granting a duration as part of resuming a subscription? >> For example if it is clear that you leave your office latest at 8 in >> the evening, and a subscription for CC arrives at your desk phone at >> 7:45, expires set to 1 hour, expires in the response should be set to >> 15 minutes. >> >>> - Section 9.5 third paragraph points to a format described in >>> section 8. It means to point to section 10. >>> >>> - The description of NOTIFY bodies in section 9.5 allows bodies of >>> type application/sdp to be sent in notifies as long as that type >>> occurs in the Accept header field of the most recent SUBSCRIBE >>> request on the dialog. Is that intentional? >>> >>> - Section 9.6 is vague about a call-completion service specific >>> timer. It points into 9.4 claiming the timer is described there, >>> but 9.4 is talking about subscription duration, only noting that >>> the duration default value is chosen based on a timer value from >>> other specifications. Why is this MAY important? What are the >>> implementations supposed to do with this implication? >>> >>> - In the second paragraph of section 9.7, should the 480 include a >>> retry-after? Why was 403 chosen for long-term-denial _error_ >>> situations. Why isn't that a 500? >>> >>> - The first sentence of section 9.8 would be much more effective if >>> it said (or pointed to text that describes) what the event >>> triggering conditions actually are. >>> >>> - The third paragraph of section 9.8 has a MUST requirement that is >>> conditional on an agent initiating an INVITE "promptly", but >>> there's no characterization of "promptly" in the document. How >>> does it account for the time it takes to reconfirm the caller is >>> actually present and available before initiating the INVITE due >>> to a recall? (This should also be accounted for in the first part >>> of the security considerations). >>> >>> - Section 9.9 (corresponding to section 4.4.8 of RFC3261) is not >>> adequate. It needs to actually describe the package specific >>> subscription processing (including how the state is built), or >>> provide a finer reference to where that specification lies than >>> "in this and possibly in other documents". Section 7 has most of >>> this information, but it's fairly widely scattered. Please >>> consider consolidating the normative behavior into one place. >>> >>> - Section 9.11 claims the service typically involves a single >>> notification per notifier per subscription. This cannot be the >>> case. There will typically be three - the initial notify in >>> response to the subscribe request, the notify representing the >>> state transition from queued to ready, and the notify >>> corresponding to the termination of the subscription. (It is not >>> clear from the document when you expect the notification of >>> "ready" to immediately terminate the subscription, if ever.) >>> >>> - The timing restrictions in section 9.11 seem artificial, and >>> interact badly with the application this package is intended to >>> support (the implication is that the server should delay send a >>> "ready" for example). Can the document explain how these >>> restrictions were chosen? >>> >>> - Why does the call-completion information format make a provision >>> for X- headers since you ignore lines with unknown names? >>> >>> - Instead of saying "Two lines with the same name MUST NOT be >>> present, except where specifically permitted", consider saying >>> "The header lines defined in this document can occur at most once >>> in any given call-completion document. Extensions must define >>> whether defined lines may occur more than once. How likely is >>> this format to be extended? Do these need to be put in a >>> registry? >>> >>> - Why does the syntax for cc-URI allow cc-URI header line >>> parameters? You certainly want the URI to be able to contain URI >>> parameters, but when would you ever use the header line >>> parameters? What you have now allows >>> >>> cc-URI: random display text >>> ;cc-uri-header-param-name >>> =cc-uri-header-param-value >>> >>> How is having that display text ever useful? When would >>> you every use >>> a cc-uri-header-param? In other words, why isn't this simply >>> cc-URI = "cc-URI" HCOLON addr-spec? >>> >>> - Item 2 in the security considerations section is unclear. It >>> seems to be placing a requirement on the subscriber (the caller), >>> but it's not clear what that requirement is (don't suspend any >>> subscriptions longer than a typical call? than some duration a >>> user entered for _this_ call? or what?). What's the subscriber >>> supposed to do if it would have suspended a subscription that >>> long - terminate the subscription? How does this protect the >>> privacy of the callee? >>> >>> - The media-type form sections should point to specific sections in >>> this document. Consider calling out the most important >>> interoperability and security considerations. >>> >>> _______________________________________________ >>> BLISS mailing list >>> BLISS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bliss >>> From david.black@emc.com Thu Aug 9 16:08:45 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBD921F85F0; Thu, 9 Aug 2012 16:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rrgaodBTzVD; Thu, 9 Aug 2012 16:08:44 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BDE6921F85DD; Thu, 9 Aug 2012 16:08:44 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q79N8fCO015783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 19:08:42 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 9 Aug 2012 19:08:21 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q79N8Iec010299; Thu, 9 Aug 2012 19:08:18 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Thu, 9 Aug 2012 19:08:18 -0400 From: "Black, David" To: "alan.b.johnston@gmail.com" , "mohsen.soroush@sylantro.com" , "vvenkatar@gmail.com" , "gen-art@ietf.org" Date: Thu, 9 Aug 2012 19:08:17 -0400 Thread-Topic: Gen-ART review of draft-ietf-bliss-shared-appearances-13 Thread-Index: Ac1Vb8Dn5IHpqMlJQDmiZm9plrtFJQL1mcsgBU9mF9A= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208F12410@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208DD8672@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208DD8672@MX15A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "bliss@ietf.org" , "Black, David" , IETF Discussion Subject: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-13 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 23:08:45 -0000 These resolutions have been carried forward to the -13 version of the draft= . Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, July 13, 2012 6:25 PM > To: Black, David; alan.b.johnston@gmail.com; mohsen.soroush@sylantro.com; > vvenkatar@gmail.com; gen-art@ietf.org > Cc: Shida Schubert; bliss@ietf.org; IETF Discussion; Robert Sparks > Subject: Gen-ART review of draft-ietf-bliss-shared-appearances-12 >=20 > The -12 version of this draft resolves all of the comments in the > Gen-ART review of the -11 version. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Black, David > > Sent: Thursday, June 28, 2012 4:51 PM > > To: alan.b.johnston@gmail.com; mohsen.soroush@sylantro.com; > > vvenkatar@gmail.com; gen-art@ietf.org > > Cc: Black, David; Shida Schubert; bliss@ietf.org; IETF Discussion; Robe= rt > > Sparks > > Subject: Gen-ART review of draft-ietf-bliss-shared-appearances-11 > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > . > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-bliss-shared-appearances-11 > > Reviewer: David L. Black > > Review Date: June 28, 2012 > > IETF LC End Date: June 28, 2012 > > IESG Telechat date: (if known) > > > > Summary: > > > > This draft is on the right track but has open issues, described in the > review. > > > > This draft describes support for shared appearances in support of multi= -line > > and shared-line telephone often found in businesses. All of the open i= ssues > > are minor. The draft is well-written and reasonably clear for the most > part, > > although significant SIP expertise is required to completely understand= it. > > > > Major issues: None. > > > > Minor issues: > > > > 4.1 - REQ-16: > > > > in this case, seizing the line is the same thing as dialing. > > > > That seems wrong - I would have thought it was a "prerequisite" as > > opposed to "the same thing" because seizing the line is immediately > > followed by a dialing request. > > > > 5.3. > > > > A user may select an appearance number but then abandon placing a > > call (go back on hook). In this case, the UA MUST free up the > > appearance number by removing the event state with a PUBLISH as > > described in [RFC3903]. > > > > What happens when that can't be done due to UA or network failure? > > > > 5.4. > > > > A 400 response is returned if the chosen appearance number is invali= d, > > > > Is that always a 400 (Bad Request) or is any 4xx response allowed? If > > it's always 400, add the words "Bad Request" after "400". > > > > If the Appearance Agent policy does not allow this, a 400 response > > is returned. > > > > Same question. In addition, is 403 Forbidden allowed here? > > > > If an INVITE is sent by a member of the group to the shared AOR (i.e= . > > they call their own AOR), the Appearance Agent MUST assign two > > appearance numbers. The first appearance number will be the one > > selected or assigned to the outgoing INVITE. The second appearance > > number will be another one assigned by the Appearance Agent for the > > INVITE as it is forked back to the members of the group. > > > > How does that interact with the single appearance UAs in 8.1.1 that won= 't > > understand the second appearance number? A warning that such a UA can'= t > > pick up its call to its own AOR would suffice, either here or in 8.1.1. > > > > 9.1 > > > > A UA that has no knowledge of appearances must will only have > > appearance numbers for outgoing calls if assigned by the Appearance > > Agent. If the non-shared appearance UA does not support Join or > > Replaces, all dialogs could be marked "exclusive" to indicate that > > these options are not available. > > > > Should that "could be marked" be changed to "SHOULD be marked" ? > > Also, analogous questions for "could" in 9.2 and "can" in 9.3. > > > > All three of these affect interoperability. > > > > 12. Security Considerations > > > > In general, this section is weak on rationale - the second, third and > > fourth paragraphs should all explain more about the purpose of and/or > > rationale for their security requirements (e.g., what does the security > > mechanism protect against and when/why might that protection be desired > > and/or required?). > > > > NOTIFY or PUBLISH message bodies that provide the dialog state > > information and the dialog identifiers MAY be encrypted end-to-end > > using the standard mechanisms. > > > > What are "the standard mechanisms"? List them, and provide references, > > please. > > > > Please ensure that the section 6 XML and Section 7 ABNF are > > syntax-checked with actual tools. > > > > Nits/editorial comments: > > > > p.10: > > > > The next section discusses the operations used to implement parts of > > the shared appearance feature. > > > > "The following list describes the operations ..." would be better. > > > > 5.3.1. > > > > A UA wanting to place a call but not have an appearance number > > assigned publishes before sending the INVITE without an 'appearance' > > element but with the 'shared' event package parameter present. > > > > I think I understand what was intended here, but this would be clearer > > if "publishes" was replaced with language about sending a PUBLISH. > > It's also not completely clear whether "without" applies to the > > INVITE or the PUBLISH, so this sentence probably needs to be reworded. > > > > 5.4. - Expand B2BUA acronym on first use. > > > > idnits 2.12.13 ran clean. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- From Martin.Huelsemann@telekom.de Wed Aug 15 08:01:51 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726FC21F855D for ; Wed, 15 Aug 2012 08:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmTVNZKr5UYF for ; Wed, 15 Aug 2012 08:01:50 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id D505721F8541 for ; Wed, 15 Aug 2012 08:01:09 -0700 (PDT) Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 15 Aug 2012 17:01:05 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.163]) by HE111296.EMEA1.CDS.T-INTERNAL.COM ([fe80::19ac:3fb4:a382:6df4%16]) with mapi; Wed, 15 Aug 2012 17:00:54 +0200 From: To: Date: Wed, 15 Aug 2012 17:00:53 +0200 Thread-Topic: AW: [BLISS] AD review: draft-ietf-bliss-call-completion-14 Thread-Index: AczwrsiU6VmeY5HYQS2aU/+PswszVCKMJYjA Message-ID: <9762ACF04FA26B4388476841256BDE020115FFE4D077@HE111543.emea1.cds.t-internal.com> References: <4F10B30A.9060203@nostrum.com> <9762ACF04FA26B4388476841256BDE020115C8FA18DA@HE111543.emea1.cds.t-internal.com> <4F43BA45.9090606@nostrum.com> In-Reply-To: <4F43BA45.9090606@nostrum.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: bliss@ietf.org, draft-ietf-bliss-call-completion@tools.ietf.org Subject: Re: [BLISS] AD review: draft-ietf-bliss-call-completion-14 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 15:01:51 -0000 Hi Robert, sorry I somehow missed this mail. Some answers inside. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Robert Sparks [mailto:rjsparks@nostrum.com] > Gesendet: Dienstag, 21. Februar 2012 16:38 > An: H=FClsemann, Martin > Cc: bliss@ietf.org; > draft-ietf-bliss-call-completion@tools.ietf.org; > dworley@avaya.com; Jesske, Roland; alexeitsev@teleflash.com; > shida@ntt-at.com > Betreff: Re: AW: [BLISS] AD review: > draft-ietf-bliss-call-completion-14 > > Thanks Martin - more comments inline. > > Will you be at the Paris IETF meeting? > > >> Major issues > >> > >> - The document's proposed use of PUBLISH is not > consistent with the > >> semantics of that method. It attempts to use PUBLISH > to affect > >> the subscription state, not the state of the event being > >> subscribed to (it's telling that PUBLISHing to this > event package > >> doesn't allow setting the state being subscribed > to). Among other > >> things, this prevents separating the state agent > from the state > >> authority. > > The concept is the following: The caller sends it's own > > status information in the PUBLISH request. In this case there > > is no change in the CC monitor (the queue) state done by the > > PUBLISH request directly, but either an indirect change of > > the state based on the information about the caller status. > > The CC monitor acts as a state composer, composing the state > > of the queue from the states of the different callers. > This isn't composition. It's conflation of unrelated things. As RFC 3863 says, the values 'open' or 'closed' of the presence basic eleme= nt also indicate the general availability for other communication means tha= n instant message, such as the availability as a (CC re-) call, so I think = there is at least a little relation. > You have an application that's operating on two unrelated > sources of information. If you really want to use sip events > to carry the information about the caller, you should be > considering a separate event package for it. A dedicated suspend/resume event package was our first idea, in my opinion = that would have been the cleanest solution. But at discussions on the maili= ng list people were very reluctant to agree on yet another event package wi= th such a limited scope, while on the other hand presence/PUBLISH conveys n= early the same information, that is if the caller is willing to accept a ca= ll or not. > If that feels > wrong, it's another sign that PUBLISH is not the hammer > you're looking for to pound on this particular nail. > > Speaking more generally to the events architecture, an > element that has enough information to act as a publisher > necessarily has the information it needs to be able to serve > subscriptions directly. It is choosing to publish to a state > agent to deal with matters outside of the contents of the > package itself (not always being connected, having limited > bandwidth, etc.). Even in an idealized presence system where > the ultimate presence document is composed from many > contributing publishers, the individual sources have enough > information (and it makes sense within the definition of the > package) to accept subscriptions to their part of the total > state. Further, subscribing to presence.winfo at the state > agent will provide meaningful data to each of the > contributing sources. But I think presence information can be used by other services to trigger c= ertain events? So it would be possible for the CC monitor to subscribe for = presence information of the caller, and act upon that? > > > > > > > > > > >> The document modifies how PUBLISH identifies the > >> resource being manipulated by looking at the From URI and not > >> only at the Request-URI. How the Callee's agent > responds to the > >> request to change this subscription state is underspecified - > >> when can it reject a request? What is the caller > supposed to do > >> if the request fails? > > As mentioned the PUBLISH is not a RPC, the CC agent on > behalf of the callee publishes information about the > reachability of the callee for CC recalls. The monitor > composes the state. This state can be used to evaluate if it > is useful to start a CC recall or not. > I think you were still trying to respond to the first point > above here. > This is a different question, and will stand independent of > what technique you use to make the request to change the > information about the caller. What happens when that request > needs to fail (due to parsing, overload, authorization, > application-specific logic, or any of the other reasons UAS > have to reject requests)? The effect of course would be that the CC service would run a less efficien= t. If the suspension fails, the monitor woud still think the caller is avai= lable for the recall and another recall would be started unnecessarily. Res= pectively CC would be deactivated after the recall timer expiry. We regarde= d this as acceptable for exceptional situations, as sus/res is not the most= important feature of the CC service. > >> - As written, there does not appear to be any protection > >> against an attacker causing everyone else that > might be in a > >> queue to be marked not-available, ensuring his > call moves to > >> the front of the queue. He only needs to know > the AoRs of the > >> callers he might be competing with and send > PUBLISH requests > >> with those AoRs in the From header field. > >> - What keeps a new caller from just adding the m=3D > attribute to > >> a new INVITE in order to get the preferential > treatment by > >> the network and the callee's UA described in > several sections > >> of the document? Was an approach that used a temp-GRUU > >> considered instead? It would not have the > property of being > >> as easy to guess as adding an m=3D URI parameter to an AoR. > > As for many mechanisms in the CC draft also here we had to > > consider the interworking to the PSTN. There we have only a > > very basic CC prioritization indicator in the IAM, saying not > > much more than 'this IAM is prioritized for CC'. That's why > > the callee's monitor MUST record the From URI from the > > initial call, to have the chance to check it against incoming > > INVITEs and verify id this INV is in fact for CC. Clarifying > > text for this is needed in the draft. > That clarifying text needs to capture the scenarios above, > and answer the questions. For instance, if there is nothing > to keep an attacker from marking everyone else in the queue > as not available, the document needs to call that out as a > security consideration. (I hope this isn't what the group > plans to end with). I hope it's more clear now in the draft, if not please indicate. > >> - What keeps this from happening? Adam calls and I > reject his call > >> because I'm waiting for another (I press X and the > phone just > >> reports that I'm busy). Adam's phone subscribes for > >> call-completion and gets a NOTIFY of "ready" - his > phone calls > >> mine again, forcing me to re-reject him. This repeats until I > >> take my phone off the hook (or engage a global DND) > causing me to > >> not be able to receive the call I was waiting for. > > If the callee's monitor does not want to enable the caller > to make use of the CC service, it will not insert a Call-Info > header field with "purpose=3Dcall-completion" in the final > response message. > Where is the text in the document that defines that behavior? > > Of course Adam's phone could try to sunscribe for CC at > your phone, but in this case your phone simply rejects the > subscription, which should not affect your reachability for > the call you are waiting for. > Similarly, where in the text is this made clear? It is > separable from the the scenario above - Adam could write a > script to subscribe to every address at an enterprise. What > normative text causes all those subscriptions to be rejected? I will check this again. From shida@ntt-at.com Wed Aug 15 10:16:32 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E08321F851A for ; Wed, 15 Aug 2012 10:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.765 X-Spam-Level: X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifRhLhSMpdCO for ; Wed, 15 Aug 2012 10:16:31 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 5540E21F8505 for ; Wed, 15 Aug 2012 10:16:22 -0700 (PDT) Received: from [172.218.64.46] (port=50692 helo=[192.168.1.76]) by gator465.hostgator.com with esmtpa (Exim 4.77) (envelope-from ) id 1T1hCb-0000HX-34; Wed, 15 Aug 2012 12:16:17 -0500 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: <9762ACF04FA26B4388476841256BDE020115FFE4D077@HE111543.emea1.cds.t-internal.com> Date: Wed, 15 Aug 2012 10:16:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <86984151-5A96-4531-BA53-8FB521C3E0E7@ntt-at.com> References: <4F10B30A.9060203@nostrum.com> <9762ACF04FA26B4388476841256BDE020115C8FA18DA@HE111543.emea1.cds.t-internal.com> <4F43BA45.9090606@nostrum.com> <9762ACF04FA26B4388476841256BDE020115FFE4D077@HE111543.emea1.cds.t-internal.com> To: X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.76]) [172.218.64.46]:50692 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 6 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: bliss@ietf.org, draft-ietf-bliss-call-completion@tools.ietf.org Subject: Re: [BLISS] AD review: draft-ietf-bliss-call-completion-14 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:16:32 -0000 Hi Robert; I think what Martin explained is along the line of what we had = discussed=20 at the IETF83..=20 1. Caller calls the callee. 2. Callee is busy so either callee or call-completion service (CC = monitor) sends back the availability of call-completion to be used.=20 3. Caller subscribes to the call-completion pkg by sending SUBSCRIBE. 4. Either at the when response with call-completion availability is = sent=20 OR at the point of receiving a SUBSCRIBE message is received,=20 call-completion service instantiate a presence (and logical = presence f server if it was the first instance of presence) for the=20 duration of the subscription to the call-completion pkg.=20 5. Caller will manipulate the presence state of its own presence at the=20= callee side..=20 6. As the queue is deleted / removed from the call-completion so does = the=20 associated instance of presence from the presence server. * Another approach is for CC monitor to subscribe to caller's presence=20= at its domain but this doesn't always work because there may not be any=20= presence server.=20 Regards Shida On Aug 15, 2012, at 8:00 AM, = wrote: > Hi Robert, >=20 > sorry I somehow missed this mail. Some answers inside. >=20 >=20 > Regards, Martin >=20 >=20 >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: Robert Sparks [mailto:rjsparks@nostrum.com] >> Gesendet: Dienstag, 21. Februar 2012 16:38 >> An: H=FClsemann, Martin >> Cc: bliss@ietf.org; >> draft-ietf-bliss-call-completion@tools.ietf.org; >> dworley@avaya.com; Jesske, Roland; alexeitsev@teleflash.com; >> shida@ntt-at.com >> Betreff: Re: AW: [BLISS] AD review: >> draft-ietf-bliss-call-completion-14 >>=20 >> Thanks Martin - more comments inline. >>=20 >> Will you be at the Paris IETF meeting? >>=20 >>>> Major issues >>>>=20 >>>> - The document's proposed use of PUBLISH is not >> consistent with the >>>> semantics of that method. It attempts to use PUBLISH >> to affect >>>> the subscription state, not the state of the event being >>>> subscribed to (it's telling that PUBLISHing to this >> event package >>>> doesn't allow setting the state being subscribed >> to). Among other >>>> things, this prevents separating the state agent >> from the state >>>> authority. >>> The concept is the following: The caller sends it's own >>> status information in the PUBLISH request. In this case there >>> is no change in the CC monitor (the queue) state done by the >>> PUBLISH request directly, but either an indirect change of >>> the state based on the information about the caller status. >>> The CC monitor acts as a state composer, composing the state >>> of the queue from the states of the different callers. >=20 >> This isn't composition. It's conflation of unrelated things. > As RFC 3863 says, the values 'open' or 'closed' of the presence basic = element also indicate the general availability for other communication = means than instant message, such as the availability as a (CC re-) call, = so I think there is at least a little relation. >=20 >> You have an application that's operating on two unrelated >> sources of information. If you really want to use sip events >> to carry the information about the caller, you should be >> considering a separate event package for it. > A dedicated suspend/resume event package was our first idea, in my = opinion that would have been the cleanest solution. But at discussions = on the mailing list people were very reluctant to agree on yet another = event package with such a limited scope, while on the other hand = presence/PUBLISH conveys nearly the same information, that is if the = caller is willing to accept a call or not. >=20 >> If that feels >> wrong, it's another sign that PUBLISH is not the hammer >> you're looking for to pound on this particular nail. >>=20 >> Speaking more generally to the events architecture, an >> element that has enough information to act as a publisher >> necessarily has the information it needs to be able to serve >> subscriptions directly. It is choosing to publish to a state >> agent to deal with matters outside of the contents of the >> package itself (not always being connected, having limited >> bandwidth, etc.). Even in an idealized presence system where >> the ultimate presence document is composed from many >> contributing publishers, the individual sources have enough >> information (and it makes sense within the definition of the >> package) to accept subscriptions to their part of the total >> state. Further, subscribing to presence.winfo at the state >> agent will provide meaningful data to each of the >> contributing sources. > But I think presence information can be used by other services to = trigger certain events? So it would be possible for the CC monitor to = subscribe for presence information of the caller, and act upon that? >=20 >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> The document modifies how PUBLISH identifies the >>>> resource being manipulated by looking at the =46rom URI and = not >>>> only at the Request-URI. How the Callee's agent >> responds to the >>>> request to change this subscription state is underspecified - >>>> when can it reject a request? What is the caller >> supposed to do >>>> if the request fails? >>> As mentioned the PUBLISH is not a RPC, the CC agent on >> behalf of the callee publishes information about the >> reachability of the callee for CC recalls. The monitor >> composes the state. This state can be used to evaluate if it >> is useful to start a CC recall or not. >> I think you were still trying to respond to the first point >> above here. >> This is a different question, and will stand independent of >> what technique you use to make the request to change the >> information about the caller. What happens when that request >> needs to fail (due to parsing, overload, authorization, >> application-specific logic, or any of the other reasons UAS >> have to reject requests)? > The effect of course would be that the CC service would run a less = efficient. If the suspension fails, the monitor woud still think the = caller is available for the recall and another recall would be started = unnecessarily. Respectively CC would be deactivated after the recall = timer expiry. We regarded this as acceptable for exceptional situations, = as sus/res is not the most important feature of the CC service. >=20 >=20 >>>> - As written, there does not appear to be any protection >>>> against an attacker causing everyone else that >> might be in a >>>> queue to be marked not-available, ensuring his >> call moves to >>>> the front of the queue. He only needs to know >> the AoRs of the >>>> callers he might be competing with and send >> PUBLISH requests >>>> with those AoRs in the =46rom header field. >>>> - What keeps a new caller from just adding the m=3D >> attribute to >>>> a new INVITE in order to get the preferential >> treatment by >>>> the network and the callee's UA described in >> several sections >>>> of the document? Was an approach that used a temp-GRUU >>>> considered instead? It would not have the >> property of being >>>> as easy to guess as adding an m=3D URI parameter to an = AoR. >>> As for many mechanisms in the CC draft also here we had to >>> consider the interworking to the PSTN. There we have only a >>> very basic CC prioritization indicator in the IAM, saying not >>> much more than 'this IAM is prioritized for CC'. That's why >>> the callee's monitor MUST record the =46rom URI from the >>> initial call, to have the chance to check it against incoming >>> INVITEs and verify id this INV is in fact for CC. Clarifying >>> text for this is needed in the draft. >> That clarifying text needs to capture the scenarios above, >> and answer the questions. For instance, if there is nothing >> to keep an attacker from marking everyone else in the queue >> as not available, the document needs to call that out as a >> security consideration. (I hope this isn't what the group >> plans to end with). > I hope it's more clear now in the draft, if not please indicate. >=20 >=20 >>>> - What keeps this from happening? Adam calls and I >> reject his call >>>> because I'm waiting for another (I press X and the >> phone just >>>> reports that I'm busy). Adam's phone subscribes for >>>> call-completion and gets a NOTIFY of "ready" - his >> phone calls >>>> mine again, forcing me to re-reject him. This repeats until I >>>> take my phone off the hook (or engage a global DND) >> causing me to >>>> not be able to receive the call I was waiting for. >>> If the callee's monitor does not want to enable the caller >> to make use of the CC service, it will not insert a Call-Info >> header field with "purpose=3Dcall-completion" in the final >> response message. >> Where is the text in the document that defines that behavior? >>> Of course Adam's phone could try to sunscribe for CC at >> your phone, but in this case your phone simply rejects the >> subscription, which should not affect your reachability for >> the call you are waiting for. >> Similarly, where in the text is this made clear? It is >> separable from the the scenario above - Adam could write a >> script to subscribe to every address at an enterprise. What >> normative text causes all those subscriptions to be rejected? > I will check this again. >=20 >=20 From Martin.Huelsemann@telekom.de Thu Aug 16 02:09:17 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A46121F854F for ; Thu, 16 Aug 2012 02:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BcBCIUmArAI for ; Thu, 16 Aug 2012 02:09:16 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9583121F852C for ; Thu, 16 Aug 2012 02:09:14 -0700 (PDT) Received: from he113414.emea1.cds.t-internal.com ([10.125.65.80]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 16 Aug 2012 11:09:11 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.163]) by HE113414.emea1.cds.t-internal.com ([2002:7cd:4150::7cd:4150]) with mapi; Thu, 16 Aug 2012 11:09:06 +0200 From: To: , Date: Thu, 16 Aug 2012 11:09:05 +0200 Thread-Topic: [BLISS] AD review: draft-ietf-bliss-call-completion-14 Thread-Index: Ac17CbkcI8I9GkSoRbm4hOr4xvjJyAAgm2Vg Message-ID: <9762ACF04FA26B4388476841256BDE020115FFE4D3B4@HE111543.emea1.cds.t-internal.com> References: <4F10B30A.9060203@nostrum.com> <9762ACF04FA26B4388476841256BDE020115C8FA18DA@HE111543.emea1.cds.t-internal.com> <4F43BA45.9090606@nostrum.com> <9762ACF04FA26B4388476841256BDE020115FFE4D077@HE111543.emea1.cds.t-internal.com> <86984151-5A96-4531-BA53-8FB521C3E0E7@ntt-at.com> In-Reply-To: <86984151-5A96-4531-BA53-8FB521C3E0E7@ntt-at.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: bliss@ietf.org, draft-ietf-bliss-call-completion@tools.ietf.org Subject: Re: [BLISS] AD review: draft-ietf-bliss-call-completion-14 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 09:09:17 -0000 Thanks Shida. I think you describe exactly the underlying model, only we have been carele= ss and have not described this aspect proper in the draft. The presence ins= tance is initiated together with the creation of the call-completion entity= . If we can agree on this model, I will cath up on this and add this model to= the draft. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Shida Schubert [mailto:shida@ntt-at.com] > Gesendet: Mittwoch, 15. August 2012 19:16 > An: H=FClsemann, Martin > Cc: rjsparks@nostrum.com; bliss@ietf.org; > draft-ietf-bliss-call-completion@tools.ietf.org; > dworley@avaya.com; Jesske, Roland > Betreff: Re: [BLISS] AD review: draft-ietf-bliss-call-completion-14 > > > Hi Robert; > > I think what Martin explained is along the line of what we > had discussed at the IETF83.. > > 1. Caller calls the callee. > > 2. Callee is busy so either callee or call-completion > service (CC monitor) > sends back the availability of call-completion to be used. > > 3. Caller subscribes to the call-completion pkg by sending SUBSCRIBE. > > 4. Either at the when response with call-completion > availability is sent > OR at the point of receiving a SUBSCRIBE message is received, > call-completion service instantiate a presence (and > logical presence f > server if it was the first instance of presence) for the > duration of the subscription to the call-completion pkg. > > 5. Caller will manipulate the presence state of its own > presence at the > callee side.. > > 6. As the queue is deleted / removed from the > call-completion so does the > associated instance of presence from the presence server. > > * Another approach is for CC monitor to subscribe to caller's > presence at its domain but this doesn't always work because > there may not be any presence server. > > Regards > Shida > > On Aug 15, 2012, at 8:00 AM, > wrote: > > > Hi Robert, > > > > sorry I somehow missed this mail. Some answers inside. > > > > > > Regards, Martin > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: Robert Sparks [mailto:rjsparks@nostrum.com] > >> Gesendet: Dienstag, 21. Februar 2012 16:38 > >> An: H=FClsemann, Martin > >> Cc: bliss@ietf.org; > >> draft-ietf-bliss-call-completion@tools.ietf.org; > >> dworley@avaya.com; Jesske, Roland; alexeitsev@teleflash.com; > >> shida@ntt-at.com > >> Betreff: Re: AW: [BLISS] AD review: > >> draft-ietf-bliss-call-completion-14 > >> > >> Thanks Martin - more comments inline. > >> > >> Will you be at the Paris IETF meeting? > >> > >>>> Major issues > >>>> > >>>> - The document's proposed use of PUBLISH is not > >> consistent with the > >>>> semantics of that method. It attempts to use PUBLISH > >> to affect > >>>> the subscription state, not the state of the event being > >>>> subscribed to (it's telling that PUBLISHing to this > >> event package > >>>> doesn't allow setting the state being subscribed > >> to). Among other > >>>> things, this prevents separating the state agent > >> from the state > >>>> authority. > >>> The concept is the following: The caller sends it's own status > >>> information in the PUBLISH request. In this case there is > no change > >>> in the CC monitor (the queue) state done by the PUBLISH request > >>> directly, but either an indirect change of the state based on the > >>> information about the caller status. > >>> The CC monitor acts as a state composer, composing the > state of the > >>> queue from the states of the different callers. > > > >> This isn't composition. It's conflation of unrelated things. > > As RFC 3863 says, the values 'open' or 'closed' of the > presence basic element also indicate the general availability > for other communication means than instant message, such as > the availability as a (CC re-) call, so I think there is at > least a little relation. > > > >> You have an application that's operating on two unrelated > sources of > >> information. If you really want to use sip events to carry the > >> information about the caller, you should be considering a separate > >> event package for it. > > A dedicated suspend/resume event package was our first > idea, in my opinion that would have been the cleanest > solution. But at discussions on the mailing list people were > very reluctant to agree on yet another event package with > such a limited scope, while on the other hand > presence/PUBLISH conveys nearly the same information, that is > if the caller is willing to accept a call or not. > > > >> If that feels > >> wrong, it's another sign that PUBLISH is not the hammer you're > >> looking for to pound on this particular nail. > >> > >> Speaking more generally to the events architecture, an > element that > >> has enough information to act as a publisher necessarily has the > >> information it needs to be able to serve subscriptions > directly. It > >> is choosing to publish to a state agent to deal with > matters outside > >> of the contents of the package itself (not always being connected, > >> having limited bandwidth, etc.). Even in an idealized > presence system > >> where the ultimate presence document is composed from many > >> contributing publishers, the individual sources have enough > >> information (and it makes sense within the definition of the > >> package) to accept subscriptions to their part of the total state. > >> Further, subscribing to presence.winfo at the state agent will > >> provide meaningful data to each of the contributing sources. > > But I think presence information can be used by other > services to trigger certain events? So it would be possible > for the CC monitor to subscribe for presence information of > the caller, and act upon that? > > > >> > >>> > >>> > >>> > >>> > >>>> The document modifies how PUBLISH identifies the > >>>> resource being manipulated by looking at the From > URI and not > >>>> only at the Request-URI. How the Callee's agent > >> responds to the > >>>> request to change this subscription state is > underspecified - > >>>> when can it reject a request? What is the caller > >> supposed to do > >>>> if the request fails? > >>> As mentioned the PUBLISH is not a RPC, the CC agent on > >> behalf of the callee publishes information about the > reachability of > >> the callee for CC recalls. The monitor composes the state. > This state > >> can be used to evaluate if it is useful to start a CC > recall or not. > >> I think you were still trying to respond to the first point above > >> here. > >> This is a different question, and will stand independent of what > >> technique you use to make the request to change the > information about > >> the caller. What happens when that request needs to fail (due to > >> parsing, overload, authorization, application-specific > logic, or any > >> of the other reasons UAS have to reject requests)? > > The effect of course would be that the CC service would run > a less efficient. If the suspension fails, the monitor woud > still think the caller is available for the recall and > another recall would be started unnecessarily. Respectively > CC would be deactivated after the recall timer expiry. We > regarded this as acceptable for exceptional situations, as > sus/res is not the most important feature of the CC service. > > > > > >>>> - As written, there does not appear to be any protection > >>>> against an attacker causing everyone else that > >> might be in a > >>>> queue to be marked not-available, ensuring his > >> call moves to > >>>> the front of the queue. He only needs to know > >> the AoRs of the > >>>> callers he might be competing with and send > >> PUBLISH requests > >>>> with those AoRs in the From header field. > >>>> - What keeps a new caller from just adding the m=3D > >> attribute to > >>>> a new INVITE in order to get the preferential > >> treatment by > >>>> the network and the callee's UA described in > >> several sections > >>>> of the document? Was an approach that used a temp-GRUU > >>>> considered instead? It would not have the > >> property of being > >>>> as easy to guess as adding an m=3D URI parameter > to an AoR. > >>> As for many mechanisms in the CC draft also here we had > to consider > >>> the interworking to the PSTN. There we have only a very basic CC > >>> prioritization indicator in the IAM, saying not much more > than 'this > >>> IAM is prioritized for CC'. That's why the callee's monitor MUST > >>> record the From URI from the initial call, to have the chance to > >>> check it against incoming INVITEs and verify id this INV > is in fact > >>> for CC. Clarifying text for this is needed in the draft. > >> That clarifying text needs to capture the scenarios above, > and answer > >> the questions. For instance, if there is nothing to keep > an attacker > >> from marking everyone else in the queue as not available, the > >> document needs to call that out as a security > consideration. (I hope > >> this isn't what the group plans to end with). > > I hope it's more clear now in the draft, if not please indicate. > > > > > >>>> - What keeps this from happening? Adam calls and I > >> reject his call > >>>> because I'm waiting for another (I press X and the > >> phone just > >>>> reports that I'm busy). Adam's phone subscribes for > >>>> call-completion and gets a NOTIFY of "ready" - his > >> phone calls > >>>> mine again, forcing me to re-reject him. This > repeats until I > >>>> take my phone off the hook (or engage a global DND) > >> causing me to > >>>> not be able to receive the call I was waiting for. > >>> If the callee's monitor does not want to enable the caller > >> to make use of the CC service, it will not insert a > Call-Info header > >> field with "purpose=3Dcall-completion" in the final response message. > >> Where is the text in the document that defines that behavior? > >>> Of course Adam's phone could try to sunscribe for CC at > >> your phone, but in this case your phone simply rejects the > >> subscription, which should not affect your reachability > for the call > >> you are waiting for. > >> Similarly, where in the text is this made clear? It is > separable from > >> the the scenario above - Adam could write a script to subscribe to > >> every address at an enterprise. What normative text causes > all those > >> subscriptions to be rejected? > > I will check this again. > > > > > > From rjsparks@nostrum.com Mon Aug 20 10:51:59 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3864D21F8650 for ; Mon, 20 Aug 2012 10:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lncnnf+oyVVf for ; Mon, 20 Aug 2012 10:51:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC18321F8674 for ; Mon, 20 Aug 2012 10:51:55 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7KHpqcm009433 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 Aug 2012 12:51:52 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <50327938.1050405@nostrum.com> Date: Mon, 20 Aug 2012 12:51:52 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Martin.Huelsemann@telekom.de References: <4F10B30A.9060203@nostrum.com> <9762ACF04FA26B4388476841256BDE020115C8FA18DA@HE111543.emea1.cds.t-internal.com> <4F43BA45.9090606@nostrum.com> <9762ACF04FA26B4388476841256BDE020115FFE4D077@HE111543.emea1.cds.t-internal.com> <86984151-5A96-4531-BA53-8FB521C3E0E7@ntt-at.com> <9762ACF04FA26B4388476841256BDE020115FFE4D3B4@HE111543.emea1.cds.t-internal.com> In-Reply-To: <9762ACF04FA26B4388476841256BDE020115FFE4D3B4@HE111543.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: bliss@ietf.org, draft-ietf-bliss-call-completion@tools.ietf.org Subject: Re: [BLISS] AD review: draft-ietf-bliss-call-completion-14 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 17:51:59 -0000 On 8/16/12 4:09 AM, Martin.Huelsemann@telekom.de wrote: > Thanks Shida. > > I think you describe exactly the underlying model, only we have been careless and have not described this aspect proper in the draft. The presence instance is initiated together with the creation of the call-completion entity. > > If we can agree on this model, I will cath up on this and add this model to the draft. > > > Regards, Martin That will help - thanks. I'll put the draft into revised-id needed. RjS > > > > > > >> -----Ursprüngliche Nachricht----- >> Von: Shida Schubert [mailto:shida@ntt-at.com] >> Gesendet: Mittwoch, 15. August 2012 19:16 >> An: Hülsemann, Martin >> Cc: rjsparks@nostrum.com; bliss@ietf.org; >> draft-ietf-bliss-call-completion@tools.ietf.org; >> dworley@avaya.com; Jesske, Roland >> Betreff: Re: [BLISS] AD review: draft-ietf-bliss-call-completion-14 >> >> >> Hi Robert; >> >> I think what Martin explained is along the line of what we >> had discussed at the IETF83.. >> >> 1. Caller calls the callee. >> >> 2. Callee is busy so either callee or call-completion >> service (CC monitor) >> sends back the availability of call-completion to be used. >> >> 3. Caller subscribes to the call-completion pkg by sending SUBSCRIBE. >> >> 4. Either at the when response with call-completion >> availability is sent >> OR at the point of receiving a SUBSCRIBE message is received, >> call-completion service instantiate a presence (and >> logical presence f >> server if it was the first instance of presence) for the >> duration of the subscription to the call-completion pkg. >> >> 5. Caller will manipulate the presence state of its own >> presence at the >> callee side.. >> >> 6. As the queue is deleted / removed from the >> call-completion so does the >> associated instance of presence from the presence server. >> >> * Another approach is for CC monitor to subscribe to caller's >> presence at its domain but this doesn't always work because >> there may not be any presence server. >> >> Regards >> Shida >> >> On Aug 15, 2012, at 8:00 AM, >> wrote: >> >>> Hi Robert, >>> >>> sorry I somehow missed this mail. Some answers inside. >>> >>> >>> Regards, Martin >>> >>> >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Robert Sparks [mailto:rjsparks@nostrum.com] >>>> Gesendet: Dienstag, 21. Februar 2012 16:38 >>>> An: Hülsemann, Martin >>>> Cc: bliss@ietf.org; >>>> draft-ietf-bliss-call-completion@tools.ietf.org; >>>> dworley@avaya.com; Jesske, Roland; alexeitsev@teleflash.com; >>>> shida@ntt-at.com >>>> Betreff: Re: AW: [BLISS] AD review: >>>> draft-ietf-bliss-call-completion-14 >>>> >>>> Thanks Martin - more comments inline. >>>> >>>> Will you be at the Paris IETF meeting? >>>> >>>>>> Major issues >>>>>> >>>>>> - The document's proposed use of PUBLISH is not >>>> consistent with the >>>>>> semantics of that method. It attempts to use PUBLISH >>>> to affect >>>>>> the subscription state, not the state of the event being >>>>>> subscribed to (it's telling that PUBLISHing to this >>>> event package >>>>>> doesn't allow setting the state being subscribed >>>> to). Among other >>>>>> things, this prevents separating the state agent >>>> from the state >>>>>> authority. >>>>> The concept is the following: The caller sends it's own status >>>>> information in the PUBLISH request. In this case there is >> no change >>>>> in the CC monitor (the queue) state done by the PUBLISH request >>>>> directly, but either an indirect change of the state based on the >>>>> information about the caller status. >>>>> The CC monitor acts as a state composer, composing the >> state of the >>>>> queue from the states of the different callers. >>>> This isn't composition. It's conflation of unrelated things. >>> As RFC 3863 says, the values 'open' or 'closed' of the >> presence basic element also indicate the general availability >> for other communication means than instant message, such as >> the availability as a (CC re-) call, so I think there is at >> least a little relation. >>>> You have an application that's operating on two unrelated >> sources of >>>> information. If you really want to use sip events to carry the >>>> information about the caller, you should be considering a separate >>>> event package for it. >>> A dedicated suspend/resume event package was our first >> idea, in my opinion that would have been the cleanest >> solution. But at discussions on the mailing list people were >> very reluctant to agree on yet another event package with >> such a limited scope, while on the other hand >> presence/PUBLISH conveys nearly the same information, that is >> if the caller is willing to accept a call or not. >>>> If that feels >>>> wrong, it's another sign that PUBLISH is not the hammer you're >>>> looking for to pound on this particular nail. >>>> >>>> Speaking more generally to the events architecture, an >> element that >>>> has enough information to act as a publisher necessarily has the >>>> information it needs to be able to serve subscriptions >> directly. It >>>> is choosing to publish to a state agent to deal with >> matters outside >>>> of the contents of the package itself (not always being connected, >>>> having limited bandwidth, etc.). Even in an idealized >> presence system >>>> where the ultimate presence document is composed from many >>>> contributing publishers, the individual sources have enough >>>> information (and it makes sense within the definition of the >>>> package) to accept subscriptions to their part of the total state. >>>> Further, subscribing to presence.winfo at the state agent will >>>> provide meaningful data to each of the contributing sources. >>> But I think presence information can be used by other >> services to trigger certain events? So it would be possible >> for the CC monitor to subscribe for presence information of >> the caller, and act upon that? >>>>> >>>>> >>>>> >>>>>> The document modifies how PUBLISH identifies the >>>>>> resource being manipulated by looking at the From >> URI and not >>>>>> only at the Request-URI. How the Callee's agent >>>> responds to the >>>>>> request to change this subscription state is >> underspecified - >>>>>> when can it reject a request? What is the caller >>>> supposed to do >>>>>> if the request fails? >>>>> As mentioned the PUBLISH is not a RPC, the CC agent on >>>> behalf of the callee publishes information about the >> reachability of >>>> the callee for CC recalls. The monitor composes the state. >> This state >>>> can be used to evaluate if it is useful to start a CC >> recall or not. >>>> I think you were still trying to respond to the first point above >>>> here. >>>> This is a different question, and will stand independent of what >>>> technique you use to make the request to change the >> information about >>>> the caller. What happens when that request needs to fail (due to >>>> parsing, overload, authorization, application-specific >> logic, or any >>>> of the other reasons UAS have to reject requests)? >>> The effect of course would be that the CC service would run >> a less efficient. If the suspension fails, the monitor woud >> still think the caller is available for the recall and >> another recall would be started unnecessarily. Respectively >> CC would be deactivated after the recall timer expiry. We >> regarded this as acceptable for exceptional situations, as >> sus/res is not the most important feature of the CC service. >>> >>>>>> - As written, there does not appear to be any protection >>>>>> against an attacker causing everyone else that >>>> might be in a >>>>>> queue to be marked not-available, ensuring his >>>> call moves to >>>>>> the front of the queue. He only needs to know >>>> the AoRs of the >>>>>> callers he might be competing with and send >>>> PUBLISH requests >>>>>> with those AoRs in the From header field. >>>>>> - What keeps a new caller from just adding the m= >>>> attribute to >>>>>> a new INVITE in order to get the preferential >>>> treatment by >>>>>> the network and the callee's UA described in >>>> several sections >>>>>> of the document? Was an approach that used a temp-GRUU >>>>>> considered instead? It would not have the >>>> property of being >>>>>> as easy to guess as adding an m= URI parameter >> to an AoR. >>>>> As for many mechanisms in the CC draft also here we had >> to consider >>>>> the interworking to the PSTN. There we have only a very basic CC >>>>> prioritization indicator in the IAM, saying not much more >> than 'this >>>>> IAM is prioritized for CC'. That's why the callee's monitor MUST >>>>> record the From URI from the initial call, to have the chance to >>>>> check it against incoming INVITEs and verify id this INV >> is in fact >>>>> for CC. Clarifying text for this is needed in the draft. >>>> That clarifying text needs to capture the scenarios above, >> and answer >>>> the questions. For instance, if there is nothing to keep >> an attacker >>>> from marking everyone else in the queue as not available, the >>>> document needs to call that out as a security >> consideration. (I hope >>>> this isn't what the group plans to end with). >>> I hope it's more clear now in the draft, if not please indicate. >>> >>> >>>>>> - What keeps this from happening? Adam calls and I >>>> reject his call >>>>>> because I'm waiting for another (I press X and the >>>> phone just >>>>>> reports that I'm busy). Adam's phone subscribes for >>>>>> call-completion and gets a NOTIFY of "ready" - his >>>> phone calls >>>>>> mine again, forcing me to re-reject him. This >> repeats until I >>>>>> take my phone off the hook (or engage a global DND) >>>> causing me to >>>>>> not be able to receive the call I was waiting for. >>>>> If the callee's monitor does not want to enable the caller >>>> to make use of the CC service, it will not insert a >> Call-Info header >>>> field with "purpose=call-completion" in the final response message. >>>> Where is the text in the document that defines that behavior? >>>>> Of course Adam's phone could try to sunscribe for CC at >>>> your phone, but in this case your phone simply rejects the >>>> subscription, which should not affect your reachability >> for the call >>>> you are waiting for. >>>> Similarly, where in the text is this made clear? It is >> separable from >>>> the the scenario above - Adam could write a script to subscribe to >>>> every address at an enterprise. What normative text causes >> all those >>>> subscriptions to be rejected? >>> I will check this again. >>> >>> >>