> > 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.
I agree that they may be separate; however they may be combined. More specifically, the outbound proxy/b2bua application server can also act as an appearance agent. > The PUBLISH/NOTIFY model is simply indicating that > a UA 'seized' a line to place an outbound call. SUBSCRIBE is also within the model. And when middle boxes like proxy/b2bua see related incoming/outgoing INVITEs, there would need to be a policy concerning when to send NOTIFY. It can seed NOTIFY per local policy 1) based upon observations or 2) wait until PUBLISH received. <snip> > 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 don't understand your interpretation of what I have been discussing. One of my comments was that it would be desirable to allow the outbound proxy/b2bua recognize that an INVITE is associated with a seized appearance. The following are a couple of options. 1) Send the PUBLISHed seized appearance number within an outbound INVITE. The outbound proxy/b2bua (also acting as the users appearance agent) could then recognize that this INVITE is associated with the seized appearance. If appropriate, the appearance content could obviously be removed from INVITE prior to proxying the request. 2) Communicate the not yet sent INVITE's Call-ID and From tag when PUBLISHing the line-seize. > I think what we are proposing is that a UA either > publish this information in *all* requests I don't understand "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 agree that there could be multiple models and approaches to all of this. I'll wait until the next version of the draft before commenting upon restricting a device to always or never use line-seize; it currently sounds like non desirable limitation. > > 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 > origination 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. According to section 5.3, the appearance agent would see the INVITE and select the appearance. Section 5.3: "A UA that does not need to select a particular appearance number (or doesn't care) would just send an INVITE as normal to place an outbound call. The Appearance Agent would select an available appearance and notify all subscribed UAs of the selection. The UA placing the call then publishes the use of this appearance number." _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
