Venkatesh,
The proxy-registrar has to deal with registrations from UAs and fork
calls to those UAs. The state agent has to deal with subscription
requests from UAs and supply notifications to those UAs. The two
populations of UAs can be different - I think this is the basis for what
is in the draft at the moment. In other words, we do not state any
requirement for the registrar and state agent to ensure that the two
populations are the same. I guess what you are saying is that an
implementation that couples the registrar and state agent in a way that
imposes constraints, there could be interoperability problems. So it is
this coupling that needs further discussion - correct?
John
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Venkatesh
Sent: 08 March 2008 18:03
To: Hutton, Andrew
Cc: [email protected]
Subject: Re: [BLISS] - MLA Forking INVITE's vs NOTIFY's
Alan, Andrew:
The whole point I was trying to make was that providing multiple
approaches for achieving a single feature is prone to interoperability
problems and defeats the charter of BLISS. The items I indicated in my
previous email are just some of the high level requirements. When you
decide to go with one approach vs. the other, there may be further
nuances an implementation may have to deal with that could potentially
cause interoperability issues.
Based on this email thread, we just concluded that the server
has to implement both the approaches on it's end to make the solution
inter-operable.... I am not sure how many in the mailing list are
comfortable with having to implement all of the flows (forking with
SUB/NOT, SUBSCRIBE/NOTIFY based, PUBLISH based) on a server and worry
testing all possible combinations for this feature. Each of these
approaches have impact on what areas of their systems they need to look
at to handle scale, solution robustness, network failure recovery and
such...... Above all, all these mechanisms are enabling one feature on
the server. It is in our best interest to pick one approach and move
forward with it as the solution. My 2 cents.
Venkatesh
On Sat, Mar 8, 2008 at 2:47 AM, Hutton, Andrew
<[EMAIL PROTECTED]> wrote:
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
