So if I interpret your explanation correctly, we are requiring an implementation to support all the mechanisms and not one or the other outlined in the draft for interoperability. I also want us to keep in mind that these requirements that I outlined below are not just requirements from a proxy/registrar and a UA, but other network elements that are mostly sitting between these boxes; most notably SBC's. May be you have more data than I do about parallel forking, multiple registrations for an AoR and such from *all* network elements than I do, but the last time we looked we had none and we spent a lot of time getting ONE SBC vendor to comply with these requirements.
Venkatesh On Fri, Mar 7, 2008 at 5:50 PM, Alan Johnston <[EMAIL PROTECTED]> wrote: > 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
