Re: [BLISS] Updated open issues list fordraft-ietf-bliss-call-completion-05

["WORLEY, Dale R (Dale)" <[e-mail]>]

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: 	[e-mail]
> 
> > 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