Re: [reSIProcate-users] Forked client subscriptions
On Thu, Nov 3, 2011 at 2:07 AM, Joegen Baclor <jbaclor@xxxxxxxxx> wrote:
> Hi,
>
> This is my first post to the mailing list. I am currently working on an RLS
> implementation for dialog-events as a commercial add-on for OpenUC. OpenUC
> is an offering of eZuce, one of the main contributor of the sipXecs project
> and sipfoundry. We have been evaluating SIP stacks in the past couple of
> months and we have decided to go with reSIProcate which timed fastest in our
> soak test. The second best contender was Sofia but reSIPprocate beats it
> CPU wise. So before delving into the actual issue I will raise in the next
> sentences, I would like to say "kudos!" to the project and its developers.
>
> Now for my issue. For about a month now, I have been developing the RLS
> implementation as I have already mentioned. Everything works great. I am
> able to create an RLS server using the resip/presSvr application as the
> basis. I am able to handle subscriptions and send notifications dynamically
> as the resource list state changes. On top of the state-agent, I created a
> client subscriber to dialog-events to watch the states of the phone as soon
> as it registers with the OpenUC registrar. This is also straight forward
> and I am able to receive state notification from the phone and is able to
> update the resource list document accordingly.
>
> The problem starts when the dialog-event watcher tries to watch an AOR that
> has multiple bindings. The OpenUC server forks the Subscription as it would
> normally do with INVITEs. This however is not handled properly by the
> client subscription handler. It seems to have no concept of Dialog-sets
> the way clientInviteSession was designed. I am new to reSIPprocate so I
> could be missing the obvious so I apologize in advance. I would appreciate
> some guidance if this is the case. However, if this limitation is accurate,
> we would like to contribute back to this project by working on an
> implementation of dialog-sets for Subscriptions.
>
> Hope to hear some feedback on this. And kudos again for a job well done.
>
> Joegen
> _______________________________________________
> resiprocate-users mailing list
> resiprocate-users@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>
Hi,
Sorry if my reply doesn't directly address the issue at hand (I
haven't had much time to look at the details) but I am quite happy to
read your comments regarding the general performance of reSIP/DUM and
I am glad to see eZuce interested in reSIProcate :)
Now back to the problem... if I understand correctly, you are sending
a SUBSCRIBE (using DUM) through a proxy/registrar where the SUBSCRIBE
ends up forked? Is the issue you are having related to not being able
to process incoming NOTIFYs from each fork (see RFC 3265 3.3.3 and
4.4.9)?
I'm thinking it shouldn't be too hard to write a test app with both
ends in reSIP/DUM that would exhibit the problem.
Regards,
Francis