Re: [reSIProcate] SIPImp application: presence and IM
SipImp has been lacking attention these days. Right now it is build on top
of TuIM that is build on top of the stack directly. This was before DUM and
helped form some background to figure out how to design DUM. What needs to
happen now is that SipIMP need to be moved to be on DUM or for TuIM to move
to be on DUM. I think this would fix several of the bugs in SipIMP.
TuIM currently supports the first model you mentioned and there has been a
bit of work to do the second but clearly it is not doing the right thing in
all cases.
On 11/22/04 11:12 AM, "Christian_Gavin@xxxxxxxxxxxx"
<Christian_Gavin@xxxxxxxxxxxx> wrote:
> While testing SIPImp I noticed the following:
>
> Even though the user interface in SIPImp allows to set the outbound proxy
> port (in my case the port is 5065), and REGISTER is sent to the correct
> port, other requests are sent to the standard port 5060 and thus unanswered
> by the server.
>
> This includes SUBSCRIBE and MESSAGE.
>
> I also noticed that SIPImp does not update the presence status by sending
> NOTIFY messages to subscribers. This brings up a more general question
> about the presence model in SIP.
>
> There seems to be 2 models:
>
> - In the older model, a client wanting to subscribe to a buddy's status
> sends a SUBSCRIBE to this buddy and this buddy will send NOTIFY messages to
> the client when his status changes. The buddy may also use REGISTER as a
> way to publish his status. The buddy keeps track of a list of subscribers
> to send NOTIFY messages to. In this case the SIP server just forwards the
> SUBSCRIBE / NOTIFY messages but doesn't do anything specific about them.
>
> - With the new PUBLISH model, it seems the server would be responsible for
> keeping track of the subscriptions, and buddies whose status change would
> send a PUBLISH to the server which in turn would send a NOTIFY to the
> client(s) subscribing. In this model clients do not have to keep track of
> subscribers, this is up to the server. The server is called a "state agent"
> in this model.
>
> Which model is reSIProcate implementing now? Also, did I understand the
> models correctly?
>
> Thanks!
> Christian Gavin
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel