Re: [reSIProcate-users] Forked client subscriptions
On 11/04/2011 09:08 AM, Francis Joanis wrote:
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
Yes I am using reSIP/DUM for the client subscription. Two problems.
The first is the absence of a method that signals to the application
layer that a subscription is forked. To have prior knowledge of this
is required so that we can properly distinguish shared resource item and
identify an opaque identity attribute for each Dialog. The other issue
is without a dialog-set, the client subscription will not be able to
unsubscribe to one specific fork since the subscription handle doesn't
have a concept of dialog-sets.