Nataraju A B wrote:
> -----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".
I see no exception here. The SUBSCRIBE transaction does eventually fail,
with an implied 408 if necessary. The question is what happens as a
result of that. The UAC can conclude that the (half) dialog created by
sending the SUBSCRIBE is now gone, but that doesn't impact any of the
actual dialogs established as a result of the NOTIFY(s) received.
*If* there had been a provisional response to the SUBSCRIBE, that had a
to-tag, then that would have established an early dialog. If so, and if
a NOTIFY had been received with the same to-tag (before or after), then
it might be appropriate to declare that dialog dead, and attempt to tear
it down by sending a reSUBSCRIBE with a zero expiration time. But
normally there will be no provisional responses, except perhaps a 100.
Paul
> 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
