I would just put a different spin on this without changing the facts:
If you *don't* terminate the subscription with your NOTIFY, then by
definition it is not the last NOTIFY, because the subscription still has
to be terminated sometime, and that will entail a NOTIFY.
So, if you sent a NOTIFY as part of handling the REFER, and have no
expectation that you will want/need to send any additional NOTIFYs about
the REFER, then you would be wise to indicate that this is the last
NOTIFY, terminating the subscription. Else you need to maintain the
subscription, respond to reSUBSCRIBE requests to refresh it if the come
in (including sending NOTIFY with current state), and when the
subscription expires you will still need to send another NOTIFY
indicating termination.
So you save yourself a lot of grief by just saying you are done.
Paul
Attila Sipos wrote:
> according to RFC 3515
>
> .4.7 Using the Subscription-State Header Field with Event Refer
>
> Each NOTIFY must contain a Subscription-State header field as defined
> in [2]. The final NOTIFY sent in response to a REFER MUST indicate
> the subscription has been "terminated" with a reason of "noresource".
> (The resource being subscribed to is the state of the referenced
> request).
>
> So it looks like the final NOTIFY MUST terminate the subscription.
>
>>> is it okay to *not* terminate this SUBSCRIBE dialog but just let
>>> it timeout on some expires like a minute (handling any SUBSCRIBE
>>> with Expires: with zero from transferor)?
>
> No.
> (maybe you have some weird use case you want to elaborate on?)
>
>
>
>
> -----Original Message-----
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> Christian Sommerfeldt
> Sent: 27 May 2009 12:36
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] subscription dialog on refer
>
> When getting an in-dialog REFER we get a new SUBSCRIBE-dialog. I wonder
> if it is mandatory to explisitly terminate (by means of "noresource")
> this latter dialog from the transfer target once it sends the last
> NOTIFY (the one with a sipfrag of 200 OK), or that it is equivaliently
> alright to have the transferor terminating it with a SUBSCRIBE having
> Expires: of zero.
>
> The question is: is it okay to *not* terminate this SUBSCRIBE dialog but
> just let it timeout on some expires like a minute (handling any
> SUBSCRIBE with Expires: with zero from transferor)?
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
