From: Jason Fischl <[EMAIL PROTECTED]> Why does this draft need to call this out? This is standard behavior. Do we really think that somebody is ever going to have two state agents with one for dialog events and one for dialog events originating from shared appearances? If that was the case, we wouldn't use dialog event for SA.
It's not particularly standard if one's background is in SIP systems that don't use state agents at all. For instance, I sat through the entire IETF presentation without realizing that the shared-appearance state agent *of necessity* services all out-of-dialog SUBSCRIBEs and PUBLISHes for dialog events (at least for the SA AORs). This has various implications for a system architecture where the domain's proxy is a *proxy* that routes all requests to the appropriate UA or server UAS for processing (as opposed to processing all non-invite usage messages itself). At first thought, it would appear that to implement SA in the sipX open-source system, the SA agent would be a state agent for the SA AORs, but dialog SUBSCRIBEs/PUBLISHes for other AORs (and non-AOR URIs) would continue to be forked/routed in the generic way. That is, the SA state agent is a state agent for a particular subset of AORs, and other AORs do not have a state agent. None of this is particularly odd, but it is confusing to someone whose background is not in the "centralized switch" universe if it isn't pointed out explicitly near the beginning. In the interests of preventing others from making the same mistake, I will write an introductory paragraph to clarify this point. Do we really think that somebody is ever going to have two state agents with one for dialog events and one for dialog events originating from shared appearances? Did you omit some words from this sentence? Dale _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
