Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07

<Martin.Huelsemann@telekom.de> Fri, 29 October 2010 12:22 UTC

Return-Path: <Martin.Huelsemann@telekom.de>
X-Original-To: bliss@core3.amsl.com
Delivered-To: bliss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39C93A6A43 for <bliss@core3.amsl.com>; Fri, 29 Oct 2010 05:22:12 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY8BHJ4i4VQs for <bliss@core3.amsl.com>; Fri, 29 Oct 2010 05:22:11 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 355073A6869 for <bliss@ietf.org>; Fri, 29 Oct 2010 05:22:09 -0700 (PDT)
Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 29 Oct 2010 14:23:57 +0200
Received: from S4DE9JSAAIL.ost.t-com.de ([10.125.177.200]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Oct 2010 14:23:55 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 29 Oct 2010 14:23:53 +0200
Message-ID: <BABF50A5EDD33C42A96DA535F1C8AA8003BF7747@S4DE9JSAAIL.ost.t-com.de>
In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E307DE1D0102@MCHP058A.global-ad.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [BLISS] WGLC for draft-ietf-bliss-call-completion-07
Thread-Index: ActrXnBRVlSZi1rZQVePKrV5OtKl7gLIePoQADIECMA=
References: <46705063-0A81-4DE5-927A-C74FC13AF6C9@agnada.com> <101C6067BEC68246B0C3F6843BCCC1E307DE1D0102@MCHP058A.global-ad.net>
From: <Martin.Huelsemann@telekom.de>
To: <andrew.hutton@siemens-enterprise.com>
X-OriginalArrivalTime: 29 Oct 2010 12:23:55.0192 (UTC) FILETIME=[276A8B80:01CB7764]
Cc: bliss@ietf.org, R.Jesske@telekom.de, shida@agnada.com
Subject: Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2010 12:22:13 -0000

Hi Andrew,

thanks for reviewing and commenting.

Please find my answers inline.


Regards, Martin

 



> -----Urspr√ľngliche Nachricht-----
> Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] 
> Im Auftrag von Hutton, Andrew
> Gesendet: Donnerstag, 28. Oktober 2010 17:37
> An: Shida Schubert; BLISS
> Betreff: Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07
> 
> Hi,
> 
> The following comments are based on feedback I obtained from 
> some developers. Sorry that they are sent last minute.
> 
> 1. Section 4.2 "Call-Completion procedures" (1st Para.). The 
> text indicates that call completion procedures are not 
> required if the callee's UAs return a success response. This 
> is incorrect and in conflict with the definition of "Failed 
> Call" in the definitions. The requirement for call completion 
> is independent of the success/failure of the SIP INVITE request.
> 
> 
> 2. Section 4.2. (2nd para.) Again it is implied that the call 
> completion procedures seems tied to the state of the 
> preceding INVITE initiated dialog with the statement 
> "Eventually, the INVITE fails, or the resulting dialog(s) are 
> terminated". However it is not the case that the call 
> completion procedures are independent of the state any 
> proceeding dialog. For example it should be possible to 
> initiate call completion even before the original INVITE 
> dialog is terminated.

I've tried to combine the 2 paragrapgs: 

"The caller's UA sends an INVITE to a request URI. One or more forks of this request reach one or more of the callee's UAs. However there might be the situation that the calling user considers the result of the call insufficient to satisfy his needs, e.g. the INVITE fails and the resulting dialog(s) are terminated, or the INVITE might succeed at some other UA."


> 
> 3. The abbreviation "CECE" should be added to the terminology section.
> 
> 4. Section 6.3. States that on receipt of a CC notification 
> the callers agent should terminate or suspend all other 
> subscriptions for the original call and even "for all other 
> original calls". I see this is only SHOULD strength but I 
> don't see why it should be necessary to suspend subscriptions 
> for all other original calls.
The agent should suspend the subscription for other originals calls, as it probably only will be able to process one CC notification at a time and therefore is not available for CC notifications of other original calls. But of course it should not terminate the subscriptions for other original calls:

"When receiving a CC notification with the cc-state set to 'ready', the caller's agent SHOULD terminate or suspend all other CC subscriptions (at other monitors) for this original call, and it SHOULD suspend all CC subscriptions for all other original calls, in order to prevent any other CC requests from this caller from being activated. The agent then determines whether the calling user is available for the CC call, usually by calling the caller's UA(s)."

> 
> 5. Section 6.2. Some clarification is needed as to the how 
> multiple monitor URI's are received and in particular whether 
> a single response could contain multiple Call-Info headers 
> with different monitor URI's.

"For CC activation the agent MUST send a SUBSCRIBE to all known monitor URIs. A monitor URI can be provided by the Call-Info header in provisional and final responses to the INVITE, sent back by the callee's CC monitor(s). Additionally, the caller's agent MU.."


> 
> 6. Section 6.4. The clause initially implies that the URI 
> from the NOTIFY should be used but does not indicate any 
> standardised strength to this requirement, and then confuses 
> things by indicating that the URI from the Call-Info header 
> (from the response to the original INVITE I assume?) can be 
> used as an alternative. This needs to be clarified and some 
> guidance on the ordering of the URI sources to be used needs 
> to be given in case there is a conflict in the URIs specified 
> by the various sources. Also it is unclear if the 'm' 
> parameter is to be taken from the Call-Info header or from 
> some other source. Can the caller's agent make up their own 
> 'm' parameter value or must only one specified to it in a SIP 
> message be used?
"If the calling user is available, the caller's agent causes the caller's UA to generate a new INVITE towards the callee. The caller MAY add a 'm' parameters , in order to specify his preferences in CC processing and to prioritize the CC call. The INVITE SHOULD be adressed to the URI specified in the NOTIFY in the cc-URI, or if not available it SHOULD use the URI returned in the Call-Info header, or if not available it SHOULD use the request-URI of the original INVITE. This may not provide ideal routing, but in simple cases it is likely to reach the desired callee/callee's monitor."


> 
> 7. Section 6.5. What strength of requirement is this, as it 
> stands it seems like a MAY since it is not stated? A similar 
> comment applies to clause 6.6 There is also a general lack of 
> definition of what is meant by "busy" in this context 
"If the caller is not available for the CC call, the CC request SHALL be suspended by the CC agent until the caller becomes not busy again. To suspend the CC request, the CC agent SHALL send a PUBLISH request to each CC monitor, giving the PIDF state 'closed' for the caller's identity as presentity."

> 
> 8. Section 6.6. The "shall" is not indicated as a standard 
> requirement but seems a little strong since the user may have 
> elected to manually suspend a CC request whilst they were 
> busy. Need to clarify that only those suspension requests 
> sent as a result of the caller being busy are being 
> considered by this clause. 
MH: I don't quite understand. Do you have some text proposal for me?


> 
> 9. Why does the last paragraph of section 7.2 start and end 
> with the "_" character?
Because I was incautious enough to let my colleague Roland edit the text ;-) 
Just some typo.

> 
> 10. Section 7.2/7.3. According to RFC 3265 a NOTIFY must be 
> sent on receipt of the initial SUBSCRIBE however there is 
> nothing in these section describing this or what the initial 
> NOTIFY would contain.
I've just added a reference to RFC 3265. The Notifier has to send a NOTIFY at once, maybe with an empty body if there is no meaningful CC state available:

"The monitor MUST be prepared to receive SUBSCRIBEs for the call-completion event package directed to the URIs of UA(s) serviced by the monitor and any URIs that the monitor provides for use in Call-Info headers. The SUBSCRIBEs SHALL be processed in accordance with the procedures defined in RFC 3265."



> 
> 11. There is a typo. in the 1st paragraph of clause 7.3 "requestst".
> 
> 12. There is a typo. in the 2nd paragraph of clause 7.3 
> "'cc-service-retention".
> 
> 13. Section 7.4 The last paragraph which states does not read 
> well and is confusing. It should I think be reworded.
"Once the CC call has been terminated, successfully or unsuccessfully, the callee's monitor's policy MAY select another CC request for activation according to the monitor's policy."

> 
> 14. Section 7.5. Section 7.3 indicates that the selection of 
> requests from a queue can be more complex than simply 
> selecting the next one but this section implies the "next" 
> request in the queue is selected.
"If the processing of a CC request results in suspending that CC request, the monitor SHALL stop the recall timer and attempt to process the another CC request in the queue according to the monitor's policy."


> 
> 15. Section 7.5. This is the 1st reference to a "recall 
> timer" but it is the subject to a mandatory requirement!
Recall timer added mandatory to the regarding sections.


> 
> 16. Section 7.6. States "Receiving a CC resumption When a CC 
> request becomes resumed, then, if the callee is not busy and 
> there is no entry in the CC queue which is currently being 
> processed, the CC monitor SHALL process the queue as 
> described above". 
> Surely the action is to restart or resume the recall timer 
> (need to define which). The reference seems inappropriate (at 
> least a reference to 7.2 is better)
I think it's 7.3. The recall is started again, incl. start of a recall timer, which I've added to the procedures of 7.3.


> 
> Regards
> Andy
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: bliss-bounces@ietf.org 
> [mailto:bliss-bounces@ietf.org] On Behalf 
> > Of Shida Schubert
> > Sent: 14 October 2010 06:13
> > To: BLISS
> > Subject: [BLISS] WGLC for draft-ietf-bliss-call-completion-07
> > 
> > 
> > This is an announcement of BLISS WG last call on "Call Completion" 
> > prior to requesting publication the document as a proposed standard.
> > 
> > This is a two week working group last call so please send your 
> > comments to the list including nits by the 29th of October.
> > 
> > http://tools.ietf.org/html/draft-ietf-bliss-call-completion-07.txt
> > 
> > Regards
> > Shida Schubert (As WG chair)
> > _______________________________________________
> > BLISS mailing list
> > BLISS@ietf.org
> > https://www.ietf.org/mailman/listinfo/bliss
> > 
> _______________________________________________
> BLISS mailing list
> BLISS@ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
>