On Wed, 2009-09-02 at 14:34 -0400, Carolyn Beeton wrote: > I am experimenting with how I could allow a mixture of sets supporting > different kinds of shared line protocols: for example, > draft-anil-sipping-bla-02 (Polycom) and draft-anil-sipping-bla-04 (the > current version of this draft - which uses a different event package), > and draft-ietf-bliss-shared-appearances (a different again event > package). > > The problem is that I need to SUBSCRIBE to each set (each contact who > has REGISTERed to the shared line) with the event package that that > set supports (for the anil drafts, anyway - the bliss draft does not > maintain a subscription from the SAA to the set). > > I first thought of creating and accepting subscriptions to all the > various flavours. However, it seems that sets in general will accept > subscriptions to any of the 'dialog;xxx' event types (both Polycom and > LG Nortel accept subscriptions to dialog event packages they do not > support). Polycom in particular accepts the subscription for > 'dialog;ma' events, even sends some NOTIFYs with this package, and > then gets very confused. > > Is there any way around having to configure, on a per-set basis, which > type of dialog event type it uses for shared lines? I had hoped to be > able to tell from how they respond to subscriptions (but perhaps this > bombarding with subscriptions wouldn't have been a good approach > anyway). There isn't anything specific enough in the Supported > headers. > > - Should I maintain lists of known user agents, and map from them to > event type (can't get the user agent from a reginfo message though)? > > - or pass this info through from config (don't even know how, can we > identify which set a subscription is from)? > - or should I just give up on this and make the admin choose one > single protocol to support?
I think that the latter is your best option at this point, but for the first release (4.2.0) it would be good enough for you to pick one that works and only support that. > Any other ideas? Multi-party testing at SIPit. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
