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]> 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]> > 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]>> 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
