hisham - comments below.
Paul
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> I don't understand the race condition you are referring to. Can you please clarify?
Brett was the one that raised the spectre of race conditions. I haven't thought enough
about whether these are real. But here they are:
Brett Tate wrote:
[snip]
> BTW, I'm not looking forward to resolving
> all the race conditions concerning target
> refreshing among all the INVITE, UPDATE,
> SUBSCRIBE, 2xx, and future requests.
>
> Over an invite-dialog, can two SUBSCRIBE's
> successfully occur in opposite directions
> at the same time? Should the Contact of
> the 2xx or SUBSCRIBE be used for the
> target refresh?
>
> Should a 2xx invite response Contact take
> precedence over a just received SUBSCRIBE?
> How do we know which was actually sent
> first by the called party?
>
> Without timestamping all requests and
> responses, one solution for all
> these race conditions is to immediately
> try multiple locations to resolve the
> ambiguity. Does anyone have another
> suggestion?
[EMAIL PROTECTED] continued:
>
> About the new SUBSCRIBE within a SUBSCRIBE dialog scenario, are you suggesting that
>it is possible subscribe to different events using the same dialog?
Yes. This is explicitly mentioned in RFC 3265.
> If so, then should this really be allowed and why?
I can't answer that. I think life would have been a lot simpler if dialogs were never
shared. I presume somebody decided they were expensive enough that it would be
valuable to share them.
> If it is allowed, why does it hurt to allow the new SUBSCRIBE to be a target
>refreshing one? (I haven't thought about this thoroughly, would it hurt when you are
>moving a dialog to another terminal. Can't think of the term used or the draft
>proposing that). These are the questions that we need scenarios for in order to
>answer.
Adam says subscribe *may* do target refresh.
>
> I think for INVITE, new INVITE within an INVITE dialog is always a reINVITE.
Yes, the second and subsequent invites in a dialog are always refreshes of the first
invite.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
