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

From: "Geoff Devine" <[email-masked]>
Date: Tue, 20 Mar 2007 06:04:15 -0400

I think this is a great first cut at requirements.  Some comments....

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.

[geoff]   I think you at least need to add a requirement REQ-2A to
administratively disable this feature or at least have a mode where
specific UA status is kept private.  In 1A2 Key Systems, you convey
"line" status (where "line" maps to an E.164 telephone number or a
private telephone number) to the other "stations" (UA's).  You don't
necessarily want to convey station status to the other stations that
share a line appearance.

 REQ-3 Calls can be joined (also called bridged or conferenced

   together) or can be picked up (taken) by another UA in the group in a

   secure way.

[geoff] Regulatory issue: In the carrier class universe, there are parts
of the world where you can ring multiple UAs but a bridging function is
forbidden.  I suggest a REQ-3A as: "It must be possible to
administratively disable the Call Join (also called bridged or
conferenced together) function."

   REQ-4 The mechanism should require the minimal amount of

   configuration.  UAs registering against the group AOR should be able

   to learn about each other and join the appearance group.

[geoff] This is in conflict with other requirements I've been listing
that imply careful administrative control of this feature set.

   REQ-5 The mechanism must scale for large numbers of appearances, n,

   and large numbers of UAs, N, without introducing excessive messaging

   traffic.

[geoff] Yes!  The first time I built this function for a PBX in 1985, an
early deployment was in a large hospital where they had a dozen hallways
of 16 examination rooms where each examination room had a feature phone
with 16 line appearances.  The traffic characteristics of that switch
were about 10x what they would have been without a key system emulation
feature.  The engineers called that deployment "The Baby Killer".  As a
practical thing, you will always have a flood of messaging since you
need to line status (Idle, Ringing, Talking, On-Hold (several flavors of
the feature), DND, ...)  to each station.  I think the requirement is
more like "... should minimize messaging traffic."

   REQ-6 Each call or session (incoming or outgoing) must be assigned a

   common "appearance" number from a managed pool administered for the

   AOR group.  Once the session has terminated, the appearance number is

   released back into the pool and can be reused by another incoming or

   outgoing session.

[geoff]  Why "appearance number"?  Using a small integer is one
possibility but there are other ways you may want to name a line
appearance.  You could use E.164 number, a URI, or any unique character
string.  

[geoff] The wording of the first sentence is a little confusing.  A
reader may interpret this as a hunting requirement.  In PSTN-land key
system emulation, an E.164 number is 1-to-1 with a line appearance
button on a station.  I think this is what you mean. 

Best regards,

Geoff

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