Alan, Andrew: The whole point I was trying to make was that providing multiple approaches for achieving a single feature is prone to interoperability problems and defeats the charter of BLISS. The items I indicated in my previous email are just some of the high level requirements. When you decide to go with one approach vs. the other, there may be further nuances an implementation may have to deal with that could potentially cause interoperability issues.
Based on this email thread, we just concluded that the server has to implement both the approaches on it's end to make the solution inter-operable.... I am not sure how many in the mailing list are comfortable with having to implement all of the flows (forking with SUB/NOT, SUBSCRIBE/NOTIFY based, PUBLISH based) on a server and worry testing all possible combinations for this feature. Each of these approaches have impact on what areas of their systems they need to look at to handle scale, solution robustness, network failure recovery and such...... Above all, all these mechanisms are enabling one feature on the server. It is in our best interest to pick one approach and move forward with it as the solution. My 2 cents. Venkatesh On Sat, Mar 8, 2008 at 2:47 AM, Hutton, Andrew <[EMAIL PROTECTED]> wrote: > Hi Venkatesh, > > The design team decided to remove all reference to third party > registration from the draft as it is not considered to be necessary or > desirable. > > Regards > Andy > > > ------------------------------ > *From:* Venkatesh [mailto:[EMAIL PROTECTED] > *Sent:* 08 March 2008 01:19 > *To:* Alan Johnston > *Cc:* Hutton, Andrew; [email protected] > *Subject:* Re: [BLISS] - MLA Forking INVITE's vs NOTIFY's > > Alan: > > Let me explain this a bit further. I definitely understand registration > and forking are part of RFC 3261. As far as I know, neither forking (let > alone parallel forking) nor third party registrations are a MUST per the > RFC..... A vendor can be perfectly compatible with RFC 3261 w/o supporting > neither of the above.... > > The Shared Line Appearance as it works (which I call proposal A below) > today relies on the following set of functionality in various components: > > Proposal A: > ========= > > 1. Ability of a registrar to accept multiple registrations for the same > AOR. > 2. Ability for a registrar to accept third party registrations. > 3. Ability of a proxy or an application server that can perform parallel > forking. > 4. A state agent that sends subscriptions for dialog-state towards > user-agents. > 5. UA's that send out subscriptions for dialog state towards the > state-agent. > > For the feature to work *all* of the above capabilities will have to be > implemented by the vendor(s). > > For the alternate proposal to work (which I call proposal B below), you > need the following: > > Proposal B: > ========= > > 1. A Registrar that needs to only accept a single registration. > 2. Any proxy (forking is not required). > 3. A state agent that sends subscriptions for dialog-state towards > user-agents. > 4. UA's that send out subscriptions for dialog state towards the > state-agent. > 5. A UA that provides a mechanism to 'alert' when an incoming NOTIFY for > 'early' dialog is received. > 6. A UA that can issue an INVITE with Replaces when the user responds to > the notification indicated in 5 above. > > The big difference between the proposals are that while (1) and (2) in > proposal (B) are fairly common and are available in any SIP application > server, requirements (1), (2) and (3) in proposal (A) are not commonly > implemented. Consider a scenario where by a registrar/proxy/state-agent > vendor implements proposal (B)..... Thus the solution has no ability to fork > in parallel or accept third party registrations (like I said this is neither > a MUST level requirement in 3261 nor a MUST level requirement for proposal > (B) compliance ).... Now a SIP phone vendor implements the feature based on > proposal (A). Both of them would be compliant with the draft but the two > solutions dont interop if you want to put the two together. > > Thanks > Venkatesh > > On Fri, Mar 7, 2008 at 4:41 PM, Alan Johnston <[EMAIL PROTECTED]> wrote: > > > 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
