Re: [reSIProcate-users] Forked client subscriptions
On 11/04/2011 11:10 PM, Francis Joanis wrote:
On Thu, Nov 3, 2011 at 9:24 PM, Joegen Baclor<jbaclor@xxxxxxxxx> wrote:
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.
Hi again,
I just tried the following, hopefully it truly emulates the same
scenario you are doing:
- DUM UAC sends SUBSCRIBE to DUM UAS
- UAS gets called back: onNewSubscription (ServerSubscription)
- UAS accepts (202) the SUBSCRIBE in the callback and sends the 202
- UAC doesn't get called back just yet (it is waiting on the first NOTIFY)
- UAS creates first NOTIFY message then sends it
- UAC gets called back: onNewSubscription (ClientSubscription)
- UAC caches the ClientSubscriptionHandle then accepts the NOTIFY
- UAS uses a copy of the first sent NOTIFY but changes its From tag so
that it represents a new Dialog, then sends it (this should simulate a
fork)
- UAC gets called back with a new subscription: onNewSubscription
(ClientSubscription)
...
You should be able to cache each forked subscription has separate
ClientSubscriptionHandles. Also, by calling
subHandle->getAppDialogSet() it actually looked like the two forked
subscriptions were assigned to the same AppDialogSet, which should
make it even easier for your app (they are actually tied together).
What you could do is store all the client subscriptions that match the
same AppDialogSet directly into your own derived AppDialogSet class.
Something like:
- onNewSubscription (clientSub)
- dynamic cast clientSub->getAppDialogSet to your own class instance
- assign clientSub to your instance's client subscription list
So, I think you should be able to achieve what you want, unless I'm
totally lost regarding the issue at hand ;)
Feel free to ask if you need help with creating a custom AppDialogSet
class and factory.
Regards,
Francis
Didn't I say I might be missing the obvious? :-) Thanks a lot! This
is basically the missing link I am looking for. I'll go tinker with
AppDialogSet and get back to you if I hit any road blocks. Thanks a
lot Francis!
Joegen