I tend to agree with Dale here. Normally, there is no state agent for
the dialog package, but this is a case where it makes sense, and is
actually required. As such, it is worth calling attention to
implementers that this state agent will need to serve all dialog state
requests.
For example, a DERIVE subscribe would need to be served by this state agent.
I do not expect any new normative language - this would just be
explanatory text there to help implementers.
Thanks,
Alan
[email protected] wrote:
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
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
