-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Monday, June 05, 2006 6:55 PM
To: Nataraju A B
Cc: 'M. Rangnathan'; 'Sip-Implementors'
Subject: Re: [Sip-implementors] RFC 3265 : Why is subscribe not a three
wayhandshake?
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.
[ABN] I almost agree with you, but in that case it would be a deviation
from general statement "every transaction must be completed with a final
response".
Is this ok ???
in that case do we need to mention this deviation in the RFC ??? or
probably this scenario could also be included in exceptional procedures
draft ???
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
