Subject: [BLISS] Some comments on draft-johnston-bliss-mla-req-00.txt

From: [email-masked]
Date: Mon, 2 Apr 2007 16:34:38 -0400

* The passage:

   group telephony feature commonly known as Bridged Line Appearance

should be:

   group >of< telephony feature>s< commonly known as Bridged Line Appearance

I've also seen the term "Shared Call Status" used.

* Given this:

   When implemented using the Session Initiation Protocol (SIP),
   it is referred to as Multiple Appearances.

why is the I-D titled "Multiple Line Appearance Feature" rather than
"Multiple Appearances Feature"?

* The introduction reads:

   This specification details a method for implementing a group
   telephony feature known in telephony as Bridged Line Appearance (BLA)
   or Multiple Line Appearance, [...]

   Different approaches will be discussed including [...]

Which does this document do, present one method or present several
methods?  I expect that it focuses on one approach which can be
implemented in several ways.  If so, the I-D needs to clearly specify
the overall approach and distinguish it from the individual methods.

* REQ-2

   REQ-2 Each UA in the group must be able to learn the call status of
   the others in the group for the purpose of rendering this information
   to the user.

Though in a traditional "key system", a UA only knows the status of
each line appearance as available/ringing/in-use, and not the status
of other UAs per se.

* REQ-5

   REQ-5 The mechanism must scale for large numbers of appearances, n,
   and large numbers of UAs, N, without introducing excessive messaging
   traffic.

Better give some idea of how large "large" is.  In the computer
science world, people can consider "large" to start at 1,000,000.
Perhaps you want to say that message traffic scales linearly with the
number of appearances.

* REQ-11

   REQ-11 The mechanism must have backwards compatibility such that a UA
   which is unaware of the feature can still register against the group
   AOR and make and receive calls.

And it should cause only minimal disruption to the MLA UAs.
Specifically, it is permitted that calls that it generates/answers are
not visible or managable by the MLA mechanism, but they must not
interfere with MLA operation for other calls.

* REQ-12

   REQ-12 The mechanism must not allow UAs outside the group to select
   or manipulate appearance numbers.

Particularly, you don't want the UA generating a call to the AOR to be
able to select the appearance number.

* REQ-15

   REQ-13 For privacy reasons, there must be a mechanism so that
   appearance information is not leaked outside the group of UAs. (e.g.
   "So who do you have on line 1?")

Are the privacy requirements for MLA any more strict than the ordinary
privacy considerations for the dialog event package?

* draft-anil-sipping-bla-04

How does this I-D relate to draft-anil-sipping-bla-04.txt?  Is this
I-D fundamentally a discussion of variations on that I-D?

* Section 5.1

   This section discusses and compares multiple methods of implementing,
   conveying, and selecting appearances in SIP while meeting the
   requirements of Section 4.  These approaches are a URI parameter and
   a SIP dialog package extension parameter.  All the approaches here
   assume the common elements and operations of Figure 1.

This is awkwardly phrased, given that you have only two alternatives.
The phrasing would be more appropriate if there were a large number of
alternatives.

   This section discusses and compares two methods of implementing,
   conveying, and selecting appearances in SIP while meeting the
   requirements of Section 4.  One approach involves a URI parameter
   and is discussed in section 5.1.1.  The other approach uses a SIP
   dialog package extension parameter and is discussed in section
   5.1.2.  Both approaches assume the common elements and operations
   of Figure 1.

Dale

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: [email-masked]
Date: Mon, 2 Apr 2007 16:35:16 -0400

From: "Elwell, John" <[email-masked]>

   > Well, we have discussed an alternative model in which instead of the 
   > INVITE being forked to all N endpoints, the endpoints first 
   > get a NOTIFY 
   > from the Appearance Agent.  If a UA wants to answer the call, 
   > it sends 
   > some kind of indication to the Appearance Agent which then causes the 
   > INVITE to get sent to the endpoint.  Now, this is a major 
   > change to the 
   > way UAs answer calls, but it might help reduce ICE and media 
   > path keying 
   > messaging.

   [JRE] You say you discussed this, but what was your reason for rejecting it?

And why is that reason not documented in the I-D?

Dale

---

From: Alan Johnston <[email-masked]>
Date: Wed, 04 Apr 2007 11:11:09 -0500

Dale,

Thanks for your comments on the draft.  See mine below.

Thanks,
Alan

>    group >of< telephony feature>s< commonly known as Bridged Line Appearance

Well, that wasn't the intent of the sentence.  The intent was to point 
out that BLA is a group feature - i.e. a feature that is more 
complicated than a feature that just involves 2 or 3 UAs as most other 
features we have discussed in the past.  We may try to expand this 
discussion to make this more clear.

> I've also seen the term "Shared Call Status" used.

I'll add it to the list ;-)

> "Multiple Appearances Feature"?

The use of line in the title was meant to help an unfamiliar reader 
understand the feature being addressed without having to read the 
abstract.  If it is confusing, we can remove it.

> the overall approach and distinguish it from the individual methods.

The former is an editing artifact.  The intent is to present several 
approaches and discuss them.

> each line appearance as available/ringing/in-use, and not the status

Right - a SIP implementation will likely provide more information than a 
key system would have - it is a user interface issue about which 
information to render to the user.

> Perhaps you want to say that message traffic scales linearly with the

That is a good suggestion.

> interfere with MLA operation for other calls.

I think we can do better than that, but we shall see in the details of 
the actual mechanism.  I agree not interfering is an important requirement.

> able to select the appearance number.

Yes - we will highlight this case.

> privacy considerations for the dialog event package?

I'm not sure.  Are you thinking about privacy within the group of UAs?

> I-D fundamentally a discussion of variations on that I-D?

No, this draft discusses various options while draft-anil-sipping-bla 
takes one of them and details the mechanism.

---

From: [email-masked]
Date: Wed, 4 Apr 2007 21:03:25 -0400

From: Alan Johnston <[email-masked]>

OK, that's my mistake -- I didn't know that there was a term "group
feature".

Looking at the comments from others, I think that keeping the
terminology consistent is going to be a major problem.  And it doesn't
help that it sounds like the terminology in the telco world is not
consistent, either.

I don't know.  I suspect that in previous systems, people haven't
worried about privacy much.  But it would not be useful to require
more privacy protection than is allowed by other features.

OK, but the major diagram seems to be taken from
draft-anil-sipping-bla, so it's not clear to the new reader how this
differs from that.  Better to explain the relationship carefully.

Dale