Hi Dale, rather late, but here are some comments. For some issues I need some more details.
Regards, Martin > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] > Im Auftrag von Dale Worley > Gesendet: Sonntag, 6. Dezember 2009 21:53 > An: BLISS > Betreff: [BLISS] Updated open issues list > fordraft-ietf-bliss-call-completion-05 > > The new -05 version of draft-ietf-bliss-call-completion moves > things along considerably. I've updated the open-issues list > (excepting the purely editorial items) and appended it to > this message. I'll follow up with fuller discussion of the > open items. > > Dale > -------------------------------------------------------------- > ---------- > [Open issues list, annotated and updated based on the -05 > draft. New text is indented.] > > Now that we are close to completion on > draft-ietf-bliss-call-completion, I am compiling a > comprehensive list of open issues. The list is divided into > three sections, which need to be tackled in order: > "Substantial" issues which involve the sequence of operations > or dataflow among the participants, "Technical" > issues like the particular format of headers, and "Editorial" > issues which are entirely about how the document is written. > The issues are assigned numbers as we insert them, starting > at 1001, 2001, or 3001, depending on the group that it was > initially inserted in. > > Status of issues (in my opinion): > > Substantial > 1001 resolved > 1002 resolved > 1003 open > 1004 resolved > 1005 resolved > 1006 resolved > 1007 resolved > 1008 open > 1009 open > 1010 open > 1011 open > Technical > 2001 resolved > 2002 resolved > 2003 resolved > 2004 open > > * 1003 Hutton: CC URI > > "Hutton, Andrew" <[email protected]> Section 5.6: > "Question: Should the callee's monitor supply a URI which > should be used in the CC call?" > I think it should. > > [Responded to. Proposed that MAY->SHOULD in section 5.7: > The notification MAY also contain also a URI which should be > used in the CC call. Text change proposed.] > > The text in question is now in 7.3: > > The notification MAY also contain a URI which should be used for > suspension requestst. > > Should we change this to SHOULD? > Sorry, I've overseen this in the last revision. As the URI is very useful to generate a specific recall, I would also propose to change it to should. This is noted for the next revision > * 1008 Absence of correlation requries elucidation of security issues > > If CC does not enforce correlation with incoming calls, we > need to document how implementations should ensure privacy. > > Section 11 (Security Considerations) needs to be updated > to take care > of this. The text in -05 still describes CC correlation. > Dale I would need some more details. > * 1009 Retain option > > We need to establish how the retain option is handled. > > I think we still need to flesh out how retain is implemented. My > impression is that in the PSTN, the two endpoints negotiate > whether retain will be used, and we need to duplicate that > process. > some conditions and assumptions we provided for the 3GPP CC service. the most important information: Agent needs to know if Monitor supports retain option or if he has to activate CC again (otherwise service fails); the retain support indication is available in the NOTIFY (cc-service-retention parameter), the interworking to TCAP CC return RetainSupported parameter is possible the less important information: Monitor needs to know if Agents supports retain option or if he can delete queue entry (otherwise service depreciation, as queue entry in not deleted in case of CC call failure and can not be used for next CC request); there is no retain support indication available in SIP (would have to be a parameter in the SUBSCRIBE) assumption for the 3GPP CC Agent's support of the reatin option: advanced SIP Agents and Monitors always support retain option, therefore the Agent's SUBSCRIBE can be interworked in TCAP CC invoke with RetainSupported parameter (which is specified for 3GPP CC) principally for the PSTN CC Agent's support of the retain option: simpler 'Agents' in other systems (PSTN) only optionally support the retain option, a missing interworking of the support indication would lead to a service depreciation because of queue entry wasting but practically: also PSTN Agents do support the retain option, therefore a service depriciation only occurs in exceptional cases; from 3GPP point of view a SIP parameter in the SUBSCRIBE to indicate retain support from a PSTN Agent to a SIP Monitor is not absolutely needed (though it would be good to have) Perhaps this helps for our further specification. > * 1010 Effect of non-correlation on the event model > > In principle, each SUBSCRIBE that arrives identifies some > particular state data. This is problematic in CC, because we > really want to have each SUBSCRIBE (or rather, each group of > SUBSCRIBEs with the same > Call-Id) to identify one "state" (whether that CC request is > chosen for callback), even if there is no overt difference > between two SUBSCRIBEs (other than a different Call-Id). If > we are doing correlation, then each SUBSCRIBE can be modeled > as monitoring the state associated with the original call. > But if we do not do correlation, SUBSCRIBEs do not map into > original calls, even in theory, and we need to construct a > new event subscription model. This is probably not > difficult, but does need to be done. > > Section 5 discusses this. I think this has not been fully > clarified, though, as section 5 says that the SUBSCRIBE is > "addressed to the managed URI" but that the CECE it refers to is > "identified by the request URI". > Also here I would need some more details. > * 1011 Forking of the CC SUBSCRIBE to multiple destinations > > Andrew Hutton notes that the SIP stack in some UAs may not be > able to send several SUBSCRIBEs to several destinations using > the same Call-Id. > > The answer is that it is not *necessary* for these SUBSCRIBEs > to be forks of the same transaction. If they have separate > Call-Ids, there are certain inefficiencies but no loss of > functionality: A monitor might receive forks of more than > one of these SUBSCRIBEs and not realize that they are merged > requests, and will establish multiple queue elements. But > only one of these queue elements will be selected for callback. > > We need to add some text to section 6.2 about this. (I > think in older > versions there was a requirement that the same Call-Id should be > used.) This shouldn't be difficult to address as it is > actually an > efficiency measure. > Maybe we could suggest the usage of the same Call ID with a SHOULD? > ** Technical > > > * 2004 Failure codes for CC SUBSCRIBE > > [New for -05.] The text is inconsistent regarding the > failure code for a CC SUBSCRIBE for a call that the monitor > has no record of: 7.2 says 404, 9.7 says 481. It seems to > me that 404 should be reserved for SUBSCRIBEs for which the > monitor cannot identify the managed AOR, and 481 used for > SUBSCRIBEs that designate a proper AOR but not a known call > for that AOR. I agree with your analysis. My proposal is to solve this inconsistency with a clear definition in subclause 9.7, and delete the regarding definitions from subclause 7.2, in order to avoid redundant specification. > > > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
