[reSIProcate] Question about handling NOTIFY responses for ServerSubscriptions

[Scott Godin]

There is bugzilla tracker setup - doesn't get much use though.  ; )

See the "List of open bugs" link on the main wiki page.

Patch looks sane to me.

Scott

On Wed, Apr 10, 2013 at 1:54 PM, Francis Joanis <francis.joanis at gmail.com>wrote:

> 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
>>>
>>
>>
>
> _______________________________________________
> 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/c0801aa2/attachment.htm>