<<<<In-Line>>>>
-----Original Message-----
From: David Stuart [mailto:[EMAIL PROTECTED]
Sent: Wed 16/07/2003 18:07
To: Paul Kyzivat
Cc: [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] Messaging question with SUBSCRIBE/NOTIFY
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.
<<<< Not really. As Paul pointed out - there is nothing wrong with your basic
model in the first approach, and this option is the most realistic. Just that by
relying on Register for status you are limiting the model. I definately think you
should look at the PUBLISH draft and all it's offerings.
Chris.
> 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
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
