Subject: [BLISS] - MLA Forking INVITE's vs NOTIFY's

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 07 Mar 2008 16:45:08 +0000

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-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Alan Johnston <[email-masked]>
Date: Fri, 07 Mar 2008 11:53:22 -0600

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

---

From: Venkatesh <[email-masked]>
Date: Fri, 7 Mar 2008 10:53:05 -0800

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

---

From: Alan Johnston <[email-masked]>
Date: Fri, 07 Mar 2008 21:20:01 -0600

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-masked] 
> <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> 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
>     >
>
>

---

From: Venkatesh <[email-masked]>
Date: Fri, 7 Mar 2008 17:18:47 -0800

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-masked]> 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
> 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.
>
> > Just to clarify what I meant by (1) below, the server implemented the
> > NOTIFY mechanism and that didn't bother to implement parallel forking
> > On Fri, Mar 7, 2008 at 2:06 PM, Venkatesh <[email-masked]
> > <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>> 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
> >         >       A UA should only register against the AOR if it is
> >         likely the UA
> >         >     will
> >         >     > In earlier discussions on the BLISS MLA draft I
> >         remember that
> >         >     the option
> >         >     > 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
> >         >     > [email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>
> >         >     [email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Venkatesh <[email-masked]>
Date: Fri, 7 Mar 2008 14:06:37 -0800

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-masked]> 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
> 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
> > On Fri, Mar 7, 2008 at 9:53 AM, Alan Johnston <[email-masked]

---

From: Venkatesh <[email-masked]>
Date: Fri, 7 Mar 2008 14:35:29 -0800

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

---

From: Alan Johnston <[email-masked]>
Date: Fri, 07 Mar 2008 19:50:55 -0600

Venkatesh wrote:
> 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:
> =========
>

Actually we removed 3rd party registrations from the draft - we need to 
discuss this in the TBD section on provisioning.

> 6. A UA that can issue an INVITE with Replaces when the user responds 
> application server, requirements (1), (2) and (3) in proposal (A) are 

Really?  I'd agree that A(2) is rare, but any decent SIP proxy/registrar 
will support A(1) and A(3). 

> implements proposal (B)..... Thus the solution has no ability to fork 
> neither a MUST level requirement in 3261 nor a MUST level requirement 

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.

If we specify this correctly, we should be guaranteed interoperability.

>
> Thanks
> Venkatesh
>
> On Fri, Mar 7, 2008 at 4:41 PM, Alan Johnston <[email-masked] 
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>     >         wrote:
>     >         >
>     >         >     Hi Andy,
>     >         >
>     >         >       monitoring the status of the MA group calls and
>     taking
>     >         or joining
>     >         >       calls, the UA SHOULD only subscribe to the
>     Appearance
>     >         Agent and not
>     >         >     However, this approach is probably not described
>     in the
>     >         non-normative
>     >         >     > appearance of an incoming call and then the UA's
>     using
>     >         >     INVITE/replaces
>     >         >     > 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.
>     >         >     >
>     >         >     > Can someone explain why the option of using the
>     NOTIFY
>     >         mechanism has
>     >         >     > been dropped ?
>     >         >     >
>     >         >     > Regards
>     >         >     > Andy
>     >         <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >         <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Alan Johnston <[email-masked]>
Date: Fri, 07 Mar 2008 18:41:00 -0600

Venkatesh,

Thanks,
Alan

---

From: Alan Johnston <[email-masked]>
Date: Fri, 07 Mar 2008 14:56:18 -0600

Venkatesh,

Thanks,
Alan

---

From: Venkatesh <[email-masked]>
Date: Fri, 7 Mar 2008 18:09:14 -0800

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-masked]> wrote:

> >     >         >     This is a useful mechanism, and it hasn't been
> dropped
> >     >         from the draft.
> >     >         >     > of the appearance agent using a NOTIFY to inform
> the
> >     >         UA sharing the

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 08 Mar 2008 10:47:41 +0000

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-masked]] 
	Sent: 08 March 2008 01:19
	To: Alan Johnston
	Cc: Hutton, Andrew; [email-masked]
	Subject: Re: [BLISS] - MLA Forking INVITE's vs NOTIFY's

	Alan:

	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-masked]> wrote:

		Venkatesh,

		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

implemented the

		
		>         > <mailto:[email-masked]
<mailto:[email-masked]>>>
		
		>         wrote:
		>         >
		>         >     Hi Andy,
		>         >
		>         >     This is a useful mechanism, and it
hasn't been dropped
		>         >       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
		>         >     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
		>         >     > of the appearance agent using a NOTIFY
to inform the
		>         UA sharing the
		>         >     > appearance of an incoming call and
then the UA's using
		>         >     > 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
		>         >     > Can someone explain why the option of
using the NOTIFY

---

From: Venkatesh <[email-masked]>
Date: Sat, 8 Mar 2008 10:03:09 -0800

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-masked]>
wrote:

>  ------------------------------
> *From:* Venkatesh [mailto:[email-masked]]
> *Sent:* 08 March 2008 01:19
> *To:* Alan Johnston
> *Cc:* Hutton, Andrew; [email-masked]
> *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....
>
> For the alternate proposal to work (which I call proposal B below), you
> need the following:
>
> Proposal B:
> =========
>
> 6. A UA that can issue an INVITE with Replaces when the user responds to
> the notification indicated in 5 above.
>
> > >         >     > calling UA of the multitude of early dialog's that
> > will be
> > >         >     created in
> > >         >     > large MLA groups.
> > >         >     >

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 9 Mar 2008 16:51:29 +0100

I guess this is where people will eat during the Phila meeting.

http://www.bliss-restaurant.com/
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Fernando Lombardo" <[email-masked]>
Date: Mon, 10 Mar 2008 18:50:01 -0000

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-masked] [mailto:[email-masked]] On Behalf
Of Venkatesh
Sent: Friday, March 07, 2008 8:09 PM
To: Alan Johnston
Cc: [email-masked]
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-masked]>
wrote:

	I understand better your comments now - thanks for explaining
further.
	See my comments below.

the
	> 4. A state agent that sends subscriptions for dialog-state
towards
	> For the feature to work *all* of the above capabilities will
have to

	> For the alternate proposal to work (which I call proposal B
below),
	> 3. A state agent that sends subscriptions for dialog-state
towards
NOTIFY
responds
(A) are

requirement

	> 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).

	> On Fri, Mar 7, 2008 at 4:41 PM, Alan Johnston
<[email-masked]

exactly to the
Dialog
	>     State Compositor.  The registration/forking part is
completely
not doesn't
	>     affect the behavior of the Appearance Agent which only
deals with
current
	
	>     >     2. You put a phone that has implemented the INVITE
based
	>     mechanism
	>     >     in discussions with multiple vendors on features as
silly as
	>     call
	
	>     >         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
	>     >         other we will be reducing the utility of the
approach.
	>      Also,
	>     >         > purpose of BLISS is inter-operability;
attempting to
	>     support
	>     >         >     This is a useful mechanism, and it hasn't
been dropped
	>     >         >       be answering incoming calls.  If the UA
is mainly
	>     >         >       monitoring the status of the MA group
calls and
the
	>     >         >     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
to inform the
	>     >         >     > This mechanism was I think proposed
because it
	>     >         >     > calling UA of the multitude of early
dialog's
	>     >         >     > Can someone explain why the option of
using the

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 Mar 2008 14:48:01 +0000

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-masked] [mailto:[email-masked]] On
Behalf Of Venkatesh
	Sent: 08 March 2008 18:03
	To: Hutton, Andrew
	Cc: [email-masked]
	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-masked]> 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-masked]] 
			Sent: 08 March 2008 01:19
			To: Alan Johnston
			Cc: Hutton, Andrew; [email-masked]
			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

				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

				
				>         > On Fri, Mar 7, 2008 at 9:53
AM, Alan Johnston
<mailto:[email-masked]>

				>         >     This is a useful
mechanism, and it hasn't been dropped
				>         >       be answering incoming
calls.  If the UA is mainly
				>         >       monitoring the status
of the MA group calls and taking
				>         >       calls, the UA SHOULD
only subscribe to the Appearance
				>         >       register against the
AOR.
				>         >     However, this approach
is probably not described in the
				>         >     Section 5 description.
We should add text there
				>         >     Is there other normative
text you think we should
				>         >     > of the appearance
agent using a NOTIFY to inform the
				>         >     > appearance of an
incoming call and then the UA's using
				>         >     > This mechanism was I
think proposed because it reduced the
				>         >     > calling UA of the
multitude of early dialog's that will be
				>         >     > Can someone explain
why the option of using the NOTIFY
				>         >     > [email-masked]
<mailto:[email-masked]>

				>         >     [email-masked]
<mailto:[email-masked]>