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
