Nataraju A B wrote:
> Second question : what should the Subscriber do if the Subscribe
> transaction times out but the NOTIFY arrives ? Should the dialog be
> deleted (presumably yes as RFC 3265 may imply) ? If so, why? (
> presumably the other end got the SUBSCRIBE and is hence sending you
> NOTIFY ).
>
> [ABN] if we do like this, then we have to mention it as an exception to
> statement mentioned in 3261 i.e., "every transaction will complete in
> itself request/response". Whereas the 2543 had the similar problem while
> handling INVITE and CANCEL.
This does seem to be a fuzzy case. There are some scenarios where all
could be well in this case.
Suppose the SUBSCRIBE goes through a proxy that doesn't Record-Route.
The SUBSCRIBE makes it to the UAS, which then sends a 200 and a NOTIFY.
The 200 is sent back along the Via path, while the NOTIFY is sent
directly to the Contact. If the proxy has crashed before it forwards the
200, then the 200 will never be received, but the NOTIFY can cause a
quite acceptable dialog to be established between UAC and UAS.
In cases when the 200 *is* received, it establishes *one* dialog, and
there will normally be a NOTIFY received on that same dialog. But that
NOTIFY may be received *before* the 200, and in addition if the request
was forked, additional NOTIFYs may be received that establish other
dialogs. When you receive the first NOTIFY of each dialog, and haven't
yet received a 200, you have no way of knowing whether a 200 is expected
on *that* dialog or not. So you don't know *which* dialog to delete.
I guess it is possible to make a case either way on this, but I would be
inclined to retain the dialog if I received the NOTIFY.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
