Re: [reSIProcate-users] Any way to kill a DUM subscription in case of deregistration?

["Brody, Chris - Acision" <chris.brody@xxxxxxxxxxx>]

> In fact, it sounds like you might be doing things a bit backwards to
> start with -- could you put together a sequence diagram to show the use
> case you're trying to handle?
> 
> /a

Here is a normal third-party registration message flow:

                 Client           S-CSCF         Application Server

REGISTER            *===============>
(Expires: 3600)                      *===============>

200 OK                               <================
                     <===============

SUBSCRIBE
(Expires: xxx)                       <=================
                     <================
202                  =================> ===============>

NOTIFY               =================>
(with PIDF)                            ================>

200 OK               <================ <================


For deregistration:

                 Client           S-CSCF         Application Server

REGISTER            *===============>
(Expires: 0)                         *===============>

200 OK                               <================
                     <===============

At this point, it is clear to both sides that the client is offline and 
probably has been shut down.

If we did not use DUM, this would be the end for us.

Assuming that we do use DUM, there is now a subscription hanging. It will send 
some extra SUBSCRIBE messages until the dialog is expired.

According to specs, we should in fact clean up the SUBSCRIBE dialog with 
SUBSCRIBE (Expires: 0). We can call AppDialogSet::end(), which in turn calls 
DialogSet::end(), and this would result in an extra message flow like:

                 Client           S-CSCF         Application Server

SUBSCRIBE
(Expires: 0)                         <=================
                     (client is deregistered, no message to client)
4xx error message                    =================>

Despite the fact that we do cleanup internal resources, this extra exchange 
seems like a waste to us since the client known to be deregistered.

What do you suggest?

Thanks,
Chris

This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.