Venkatesh, Thanks for the clarification to your question - it gets exactly to the issue.
The Appearance Agent doesn't do the forking - it is just a Dialog Event State Compositor. The registration/forking part is completely separate - it is defined in RFC 3261. That is why this works - if a UA sends a REGISTER, it will get a forked INVITE. If it doesn't, it won't. Whether it registers or not doesn't affect the behavior of the Appearance Agent which only deals with dialog package subscriptions. And note that 2 (INVITE only) is not an option with the current mechanism - the UA must subscribe to the Appearance Agent. Thanks, Alan Venkatesh wrote: > Just to clarify what I meant by (1) below, the server implemented the > NOTIFY mechanism and that didn't bother to implement parallel forking > when an incoming call arrives. > > Venkatesh > > On Fri, Mar 7, 2008 at 2:06 PM, Venkatesh <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > I am looking at the feature from an overall solution > perspective.... Consider the following scenario. > > 1. The State-Agent has implemented the NOTIFication based > mechanism (new mechanism) for enabling Shared Lines. > 2. You put a phone that has implemented the INVITE based mechanism > (old mechanism) for supporting Shared Lines. > > Both of them would claim compliance with this draft. I have been > in discussions with multiple vendors on features as silly as call > hold that I am wary of providing multiple choices from an > implementation perspective. > > Venkatesh > > > On Fri, Mar 7, 2008 at 12:56 PM, Alan Johnston > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > Venkatesh, > > I don't understand the interop failure possibility - perhaps > you can > elaborate? > > The REGISTER and SUBSCRIBE are sent to different entities > (Registrar vs > Appearance Agent). It is entirely up to a UA to do one, both, or > neither. In any case, the result is well known and there is no > interaction I'm aware of. > > Both approaches have their use cases - if we force one and > disallow the > other we will be reducing the utility of the approach. Also, > because of > backwards compatibility, we must deal with this situation anyway. > > Thanks, > Alan > > > Venkatesh wrote: > > IMO, we should go with one approach vs. the other rather > than trying > > to accomodate both approaches. Especially, keeping in mind > the entire > > purpose of BLISS is inter-operability; attempting to support > both > > approaches will sure break this goal. > > > > Thanks > > Venkatesh > > > > On Fri, Mar 7, 2008 at 9:53 AM, Alan Johnston > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> > wrote: > > > > Hi Andy, > > > > This is a useful mechanism, and it hasn't been dropped > from the draft. > > Here is a paragraph in Section 6.2: > > > > A UA should only register against the AOR if it is > likely the UA > > will > > be answering incoming calls. If the UA is mainly > going to be > > monitoring the status of the MA group calls and taking > or joining > > calls, the UA SHOULD only subscribe to the Appearance > Agent and not > > register against the AOR. > > > > However, this approach is probably not described in the > non-normative > > Section 5 description. We should add text there > describing it. > > > > Is there other normative text you think we should > include to describe > > this option? > > > > Thanks, > > Alan > > > > Hutton, Andrew wrote: > > > Hi All, > > > > > > In earlier discussions on the BLISS MLA draft I > remember that > > the option > > > of the appearance agent using a NOTIFY to inform the > UA sharing the > > > appearance of an incoming call and then the UA's using > > INVITE/replaces > > > to pickup the answer/pickup the call. > > > > > > This mechanism was I think proposed because it reduced the > > impact on the > > > calling UA of the multitude of early dialog's that will be > > created in > > > large MLA groups. > > > > > > However this mechanism seems to have at some point > been dropped > > and now > > > the draft only talks about forking INVITE's. > > > > > > Can someone explain why the option of using the NOTIFY > mechanism has > > > been dropped ? > > > > > > Regards > > > Andy > > > _______________________________________________ > > > BLISS mailing list > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > > https://www.ietf.org/mailman/listinfo/bliss > > > > > > > > > > > > > _______________________________________________ > > BLISS mailing list > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > https://www.ietf.org/mailman/listinfo/bliss > > > > > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
