Hisham,
I'm still thinking about the potential race conditions, so I'm not yet prepared to
take a strong position on this. But *if* the issues exist, then I don't think your
suggestion solves them. Not only should you restrict to the method that created the
dialog - you should also restrict to the particular X (I don't know what to call it -
session, usage, ...) on the dialog. Specifically, suppose a dialog was created by a
SUBSCRIBE, and then another unrelated subscribe is done within the same dialog. If you
are trying to restrict what can update the target, then perhaps you should restrict to
just that first subscribe "session".
Paul
[EMAIL PROTECTED] wrote:
>
> May I suggest that we only allow target refresh requests to have the same method as
>the request that created the dialog. i.e.: only a reINVITE can be target refresh
>requests for a dialog created by INVITE, only reSUBSCRIBE can be target refresh
>requests for a dialog created by SUBSCRIBE.
>
> For a dialog created by INVITE, a SUBSCRIBE does not update the target. For a dialog
>created by SUBSCRIBE, an INVITE does not update the target.
>
> This is the only way to do it to avoid complexity and confusion. Otherwise you got
>to start asking about REFER and other extensions that create dialogs.
>
> I would prefer implementors to be able to build a generic dialogs module in their
>stack that doesn't need to know about methods. I mean what if I send a MESSAGE within
>a dialog? my generic dialogs module no longer can be method agnostic because it has
>to know that MESSAGE does not refresh a target, but it has to know that SUBSCRIBE
>does... too complicated.
>
> In my suggestion, a dialog state would include the method that created the dialog,
>call it dialog-method, and only requests with methods that match the dialog-method
>are target refresh requests.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
