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

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Wed, 7 Jul 2010 22:51:35 -0400

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

---

From: <[email-masked]>
Date: Tue, 20 Jul 2010 09:45:10 +0200

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

Best Regards

Roland and Martin 

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

Dale
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss