> > 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" behavior in the IMS environment. > I am not sure of the reason for this > deviation from the RFCs.
Sending a NOTIFY for a REFER was not part of the original transfer drafts. Vendors should follow the rfc and send notify when required. However I also think that it would be incorrect for a vendor to wait indefinitely for a notify. If refer is sent over an established dialog, sending one notify to terminate the subscription is considered by some to be friendly but useless. It friendly because it follows the rfc and allows the referrer and proxies to clean up the subscription more quickly. It is useless because no vendor should wait indefinitely for a notify. > 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. When the REFER 2xx response is received, start a timer. If no notify is received within the interval, delete the subscription. If a notify arrives later, return a 481 if the dialog no longer exists. _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
