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]>> 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]> > > https://www.ietf.org/mailman/listinfo/bliss > > > > > > > > _______________________________________________ > BLISS mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/bliss > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
