See inline. > > Even if the INVITE originated dialog is > > ended with a BYE, the subscription will > > persist. How could we end this Subscription, > > when the call goes away. > > Not sending a NOTIFY is considered an abnormal situation. > All involved > devices should eventually clean up the subscription based > upon their local > policies. And if not, they have put themselves at the mercy of > flaky/misconfigured networks and non compliant devices. Unfortunately, not sending a NOTIFY is the "NORMAL" behaviour in the IMS environment. I am not sure of the reason for this deviation from the RFCs. > > If a device has not sent the first notify within one minute > of releasing the > call, that device is non compliant or is unable to deliver the notify. > > > > Would it help if the referring agent sends > > a SUBSCRIBE message with a Expires timer > > set to 0 ?. > > It might help cleanup proxies that actually care. It is > likely not needed > or wanted by the notifier. If a notify finally arrives, a > 481 should be > returned (assuming the dialog has been terminated). If a > notify is unable > to be delivered because of a request timeout, the notifier > should delete the > subscription.
I am trying to find an optimal solution for cleaning up the resources allocated for the implicit subscription on the UAC (that sent the REFER), in the event the NOTIFY is not received. _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
