Re: [BLISS] call-completion open issue 1011: Forking of the CC SUBSCRIBE to multiple destinations

Hi all,
This is noted for the revision. The proposed text clarifies the issue.

Best Regards

Roland and Martin 

-----Ursprüngliche Nachricht-----
Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] Im Auftrag von WORLEY, Dale R (Dale)
Gesendet: Donnerstag, 8. Juli 2010 04:52
An: bliss@ietf.org
Betreff: [BLISS] call-completion open issue 1011: Forking of the CC SUBSCRIBE to multiple destinations

The conversation so far:

> > * 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?

I think we are all agreed that this should be a SHOULD.  We could add the following paragraph after the first paragraph of 6.2:

    To minimize redundant subscriptions, these SUBSCRIBEs SHOULD have the
    same Call-Id, that is, be presented as forks of the same transaction,
    if the caller's agent is capable of doing so.

Dale
_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss