[reSIProcate] Question about handling NOTIFY responses for ServerSubscriptions

[Francis Joanis]

Hi,

Thanks for the explanation about RFC 5057. In the end I haven't changed the
actual code regarding the destruction of the usage... I only added code to
support a new ServerSubscriptionHandler::onNotifyAccepted method. Should we
think about setting up an issue tracker for the project - unless we already
have one that I don't know about?

I've attached the patch to this email, I'll submit it later this week if no
issue comes up.

Thanks again,
Francis


On Fri, Mar 29, 2013 at 9:06 AM, Scott Godin <sgodin at sipspectrum.com> wrote:

> Hi Francis,
>
> Its important to note here that it doesn't dispatch to all subscriptions,
> its only the subscriptions within the same Dialog.  RFC5057 - discusses
> multiple dialog usages and recommend a behaviour.  Basically it depends on
> the failure response code - check out section 5.1.  It looks like someone
> attempted to implement this logic however I don't think it's quite right.
>  For example:  If the failure code is a Transaction or Dialog Usage class
> error, then other usages shouldn't be terminating as well.  On these
> classes of error server subscription should either be checking if the
> response is for its Usage, or we should push the
> Helper::determineFailureMessageEffect logic back to Dialog.cxx, so it can
> dispatch appropriately.
>
> For 200 responses it makes sense to target only the matching Usage via
> findMatchingServerSub.
>
> Scott
>
> On Tue, Mar 26, 2013 at 10:34 AM, Francis Joanis <francis.joanis at gmail.com
> > wrote:
>
>> Hi guys,
>>
>> We need to add a callback like
>> ServerSubscriptionHandler::onNotifyAccepted (similar to onNotifyRejected)
>> but I stumbled over the following in Dialog.cxx:
>>
>> At line 804 (in Dialog::dispatch) we see that all incoming errors for
>> NOTIFY messages are sent to all subscriptions. Do you think this is correct
>> (also see comment at line 795 which pretty much asks the same question)?
>>
>
>
>>
>>
> I'm asking because we would need to add another if statement so that
>> 200-class responses are sent to the ServerSubscription to call the new
>> onNotifyAccepted handler. I'm a little cautious about blindly sending all
>> 200-class messages to all subscription members of mServerSubscriptions...
>> I'd rather use Dialog::findMatchingServerSub to find the proper one.
>>
>> Also, what would be a case for having multiple server subscriptions in
>> the same Dialog? Maybe the only case where there could be multiple server
>> subscriptions in the same dialog would be if an InviteSession would process
>> multiple REFERs (w/ sub) at the same time... For an actual UAS SUBSCRIBE
>> dialog I wonder if that would even be possible.
>>
>> Thanks a lot,
>> Francis
>>
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20130410/678fdf05/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: notify_accepted_callback.patch
Type: application/octet-stream
Size: 3093 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20130410/678fdf05/attachment.obj>