I understand better your comments now - thanks for explaining further. See my comments below.
Venkatesh wrote: > 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). Actually we removed 3rd party registrations from the draft - we need to discuss this in the TBD section on provisioning. > > 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. Really? I'd agree that A(2) is rare, but any decent SIP proxy/registrar will support A(1) and A(3). > 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 ).... Except we call it a "forking proxy" in the document which would rule out a proxy that did not fork and only accepted one Contact per AOR. > 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. Right. So we can say that a forking proxy/registrar compliant to this feature MUST support A(1) and A(3). An Appearance Agent MUST support A(4). UA compliant to this feature MUST support A(5) and MAY/SHOULD support B(5) and B(6). If we specify this correctly, we should be guaranteed interoperability. > > Thanks > Venkatesh > > On Fri, Mar 7, 2008 at 4:41 PM, Alan Johnston <[EMAIL PROTECTED] > <mailto:[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]> > > <mailto:[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]> > <mailto:[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]>> > > > <mailto:[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]>> > > <mailto:[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]>> > > <mailto:[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
