While I agree that A(1) would cause problems with other network elements (a.k.a. SBCs), there are ways to get around the constraint and since most SBCs are B2BUAs it is hard to cover all use cases for a NE that is not even defined by IETF. If there are other NEs besides SBCs that are of concern, then we should discuss the uses cases in the draft... -fernando
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Venkatesh Sent: Friday, March 07, 2008 8:09 PM To: Alan Johnston Cc: [email protected] Subject: Re: [BLISS] - MLA Forking INVITE's vs NOTIFY's 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
