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
