No, its more like servers must support both mechanisms and clients may pick either.
Anyway, we really can't forbid standard SIP behavior such as proxy forking or subscribing without registering. This would break backwards compatibility with non-MA UAs and proxies. Or is this requirement not important to you? Thanks, Alan Venkatesh wrote: > 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] > <mailto:[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]> > > <mailto:[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 > > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
