Subject: [BLISS] Shared Appearances Open Issue: Publish to AOR

From: Alan Johnston <[email-masked]>
Date: Wed, 19 Nov 2008 13:18:25 -0600

This open issue relates to the Request-URI used by UAs to publish dialog 
event information to the Appearance Agent which acts as a state agent 
and event state compositor for the dialog package for the AOR.

Currently, the draft says the Request-URI must be provisioned or 
constructed by some convention (e.g. sip:[email-masked]).

Comments in the room were strongly in favor of instead just using the 
shared appearance AOR.  This simplifies operations and does not require 
any provisioning.

One consequence of this, pointed out by Dale Worley, is that the 
Appearance Agent must be prepared to handle all SUBSCRIBEs and PUBLISHes 
for the dialog events for this AOR, not just the ones used for 
implementing shared appearances.  Since the Appearance Agent is 
essentially just a state agent that also inserts additional information 
about appearances, this should not be a problem.  We need to give this a 
little more thought to make sure this is reasonable and does not cause 
problems for proxy routing logic.

In addition, the draft needs to have some text clearly describing this 
and Dale has volunteered to submit some.

Thanks,
Alan

_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Jason Fischl <[email-masked]>
Date: Wed, 19 Nov 2008 13:48:50 -0600

On Nov 19, 2008, at 1:18 PM, Alan Johnston wrote:

> Appearance Agent must be prepared to handle all SUBSCRIBEs and  
> PUBLISHes for the dialog events for this AOR, not just the ones used  
> for implementing shared appearances.  Since the Appearance Agent is  
> essentially just a state agent that also inserts additional  
> information about appearances, this should not be a problem.  We  
> need to give this a little more thought to make sure this is  
> reasonable and does not cause problems for proxy routing logic.
>
> In addition, the draft needs to have some text clearly describing  
> this and Dale has volunteered to submit some.
>
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.

Jason

---

From: [email-masked]
Date: Thu, 20 Nov 2008 14:22:26 -0500 (EST)

From: Jason Fischl <[email-masked]>

   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