[reSIProcate] Query regarding queuing mechanism for NOTIFYs (ClientSubscription)

[Byron Campen]

	If the app defers calling acceptUpdate() (or rejectUpdate()) long  
enough that the NOTIFYs pile up, and then calls end(), then yes, it  
will not get callbacks for the NOTIFYs in the queue. However, it  
should be getting a callback for the NOTIFY terminated, _provided_ a  
NOTIFY terminated has come in (if the app has deferred answering the  
NOTIFYs for this long, the notifier may well give up on the  
subscription, and reject the unSUBSCRIBE).

Best regards,
Byron Campen


> Hello,
>
> According to current queuing mechanism for NOTIFY in  
> ClientSubscription,
> if you application call end() to terminate subscription and at that  
> time
> ClintSubscription already have more then one queued NOTIFY. And  
> after some
> time DUM also getting NOTIFY with terminate state which will also  
> queued in
> NOTIFY queue.
>
> In above case application never get callback "onTerminate or  
> onUpdateActive"
> for remaining queued NOTIFYs.
>
> Am I right in above case?
>
> Thanks,
> Parag Patel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel