Re: [reSIProcate] Question about handling NOTIFY responses for ServerSubscriptions

[Francis Joanis <francis.joanis@xxxxxxxxx>]

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@xxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

Attachment: notify_accepted_callback.patch
Description: Binary data