I agree with Brett. IMS is just broken here. You should report it as a bug. As long as it does this it is not compliant with the specification of REFER. The NOREFERSUB will provide a way to achieve this result. In absence of that IMS should be sending the NOTIFY.

        Paul

Shekar, Nagesh Soma (Shekar)** CTR ** wrote:
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


_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to