On Wed, 2003-07-16 at 11:38, Paul Kyzivat wrote: > > > +------------+ +--------------+ +-------------+ > > | | | proxy/ | | | > > | UA1 | | registrar | | UA2 | > > +-----+------+ +-------+------+ +------+------+ > > | | | > > | SUBSCRIBE | | > > +-------------------------> | > > | OK | | > > <-------------------------+ | > > | NOTIFY | | > > <-------------------------+ | > > | OK | | > > +-------------------------> | > > | | REGISTER | > > | <------------------------+ > > | | OK | > > | +------------------------> > > | NOTIFY | | > > <-------------------------+ | > > | OK | | > > +-------------------------> | > > This could be considered valid, but IMHO isn't a mainstream approach. > > The proxy/registrar/pa isn't technically doing anything wrong. But > presumably it is getting all of its information from the register > message. This may be sufficient for open/closed, but its not clear how > it would get any more presence information.
Yes, I've often wondered about this as well. Considering the NOTIFY bodies are extensible (at least with cpim-pidf+xml format) it's difficult to see how the registrar could derive this. This sort of argues for the second approach. > You could couple this with UA2 sending PUBLISH messages to its own AOR, > which would be handled by the PA function of the server. Then it would > make more sense. I'm not familiar with the PUBLISH request, I will look into it.. > > +-----------+ +--------------+ +--------------+ > > | | | proxy/ | | | > > | UA1 | | registrar | | UA2 | > > +-----+-----+ +-------+------+ +-------+------+ > > | SUBSCRIBE | | > > +----------------------> | > > | PENDING | | > > <----------------------| SUBSCRIBE | > > | -------------------------> > > | | OK | > > | OK <------------------------+ > > <----------------------| | > > | | | > > | | | > > | NOTIFY | > > <-----------------------------------------------+ > > | OK | > > +-----------------------------------------------> > > | | | > > I'm not sure about this because I don't know what you intend by the line > marked PENDING. If you mean this to be a 100 response, then this could > be ok. Yes, actually it's a 100-level response. I probably shouldn't have used the "PENDING" word.. > > +------------+ +--------------+ +---------------+ > > | | | proxy/ | | | > > | UA1 | | registrar | | UA2 | > > +-----+------+ +-------+------+ +-------+-------+ > > | SUBSCRIBE | | > > +----------------------> | > > | PENDING | | > > <----------------------+ SUBSCRIBE | > > | ----------------------> > > | | OK | > > | OK <---------------------+ > > <----------------------+ | > > | NOTIFY | | > > <----------------------+ | > > | OK | | > > +----------------------> | > > | NOTIFY | > > <--------------------------------------------+ > > | OK | > > +--------------------------------------------> > > | | | > > | | | > > This isn't a good situation. The presence event package says that > subscriptions aren't supposed to be forked. UA1 doesn't know what to do > with notifications from different sources. I tend to agree ... I think what's happening in my case is that I have a registrar/proxy configured to act as in example #1, but it's also doing something strange by proxying the original subscribe request. Thanks for the input ... -- David Stuart, SIPQuest phone: 254-8886 x234 web: http://www.sipquest.com/ _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
