I am starting to respond to Martin's response to my "open issues list" message. This message is primarily for Martin (who is editing the -06 version of the draft), but is also intended for the Bliss community.
Regarding these issues: * 1011 Forking of the CC SUBSCRIBE to multiple destinations * 2004 Failure codes for CC SUBSCRIBE > From: [email protected] > > > From: Dale Worley > > Subject: [BLISS] Updated open issues list for > > draft-ietf-bliss-call-completion-05 > > > * 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? Yes, I agree, "SHOULD" captures what we want to say. > > * 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. Yes, that sounds like a good idea. Perhaps add a reference from 7.2 to 9.7. Dale _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
