Re: [reSIProcate-users] Forked client subscriptions
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