Hi all, This is noted for the revision. The proposed text clarifies the issue.
Best Regards Roland and Martin -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von WORLEY, Dale R (Dale) Gesendet: Donnerstag, 8. Juli 2010 04:52 An: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
