Replies Inline.... On Tue, Oct 21, 2008 at 7:31 AM, Brett Tate <[EMAIL PROTECTED]> wrote:
> > > If an appearance number has been explicitly > > > seized using PUBLISH, it would seem desirable > > > to include the appearance number within the > > > INVITE to reduce confusion. Without such > > > explicit indication, the Appearance Agents's > > > involvement with the outbound INVITE would be > > > required to make assumptions to correlate the > > > successful PUBLISH to INVITE. > > > > Well, I think loose coupling between the > > appearance agent and the proxy is actually a > > good thing for the design. And architects can > > always tightly couple them without any problems. > > > > Here's how I look at it. The PUBLISH to seize > > the appearance is just that - it just reserves > > it for a particular UA in the appearance group. > > At that point, it should not be tied to any > > specific call - it is up to the UA what to do > > with the appearance. Shortly after, the INVITE > > is sent - at this point, there is not tight > > coupling either, but there is no need for it. > > As soon as an early dialog is created with a 18x > > or a dialog with a 2xx, then the UA sends > > another PUBLISH. At this point the appearance > > is correlated with the dialog, and this is when > > it needs to be. The appearance agent shares > > this information with the other UAs in the > > group. Unless there is some requirement that we > > haven't discussed, I think this works. > > For a line-seize call setup, the appearance agent would be sending some > useless notifies associated with the INVITE until the caller PUBLISHes > that the INVITE is associated with the seized appearance. More > specifically, appearance agent may send NOTIFY without appearance for > the 18x dialog and then have to send another one when the caller decides > to PUBLISH that the dialog is associated with the seized appearance. [Venkatesh] I am not sure why you classify this as useless? Your source of confusion probably comes from combining the "appearance agent" function with call/INVITE processing. Infact these are two different applications and are orthogonal to each other. The PUBLISH/NOTIFY model is simply indicating that a UA 'seized' a line to place an outbound call. It can choose to provide the SIP dialog related information once the call is established or when it believes it is ready to provide this information to other parties in the group. For example, you may delay providing the SIP dialog ID's until a user places the call on hold at which point, a "call pickup" requires knowledge of the dialog. If I understand your argument correctly, what you are describing is a UA that advertises line seize information in the PUBLISH in 'arbitrary' messages even with in the same call? I think what we are proposing is that a UA either publish this information in *all* requests if it wants to use the line seize or not advertise it at all and let the "appearance agent" handle this for the UA. The UA needs to decide what model it wants to use and stick to it once it decides on the approach? > > > I'd prefer the caller be able to communicate such information within the > outgoing INVITE. > > Similarly for origination situation without PUBLISH line-seize, section > 5.3 indicates appearance agent selects the appearance. If there is an > allocated seized appearance (obtained from PUBLISH) without > corresponding INVITE, is appearance agent supposed to allocate a non > seized appearance or assume INVITE corresponds to the seized appearance? [Venkatesh] I am not I understand your question? The "appearance agent" has nothing to do with orgination INVITE processing and does not allocate a "line" when a INVITE is received. Infact, it is not even required to see the origination INVITE. If it receives a PUBLISH w/o a specific request for a line for a "dialog" it allocates a free line. It associates the line with the "dialog id" in the PUBLISH payload and uses this information for construction dialog states for subsequent PUBLISH requests. > > > Thanks, > Brett > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss >
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
