Hi Venkatesh,
The design team decided to remove all reference to third party
registration from the draft as it is not considered to be necessary or
desirable.
Regards
Andy
________________________________
From: Venkatesh [mailto:[EMAIL PROTECTED]
Sent: 08 March 2008 01:19
To: Alan Johnston
Cc: Hutton, Andrew; [email protected]
Subject: Re: [BLISS] - MLA Forking INVITE's vs NOTIFY's
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
