Section 6.1.3 describes a <joined-dialog> element which uses the id attribute of the dialog element to identity which dialogs are joined. Unfortunately, the id attribute is only unique for a UA instance. This requires that the state compositor MUST be prepared to offer different notification documents(for the same dialog) for the UAs that have conflicting id attributes.
An alternate approach would be to not use the id portion of the dialog element to identity a joined dialog. It would still have call-id, local-tag, remote-tag and direction. This eliminates the need for a state compositor to provide different views; in fact, no composition will be required within a dialog-info element. I am not sure why we didn't do that in the first place. Interestingly, I couldn't find any text in rfc4235 around id attribute collisions. It seems they lose meaning when different UAs sharing an aor are composed in a central state agent. -Derek _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
