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

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

From: "Geoff Devine" <[email-masked]>

   In PSTN-land key system emulation, an E.164 number is 1-to-1 with a
   line appearance button on a station.

It's a little stranger than that, though.  In the machinery, each line
appearance button corresponds to one DN.  But as users think about it,
often one DN will hunt to a series of other DNs, and they will think
of the buttons for all of those DNs as repetitions of the primary DN.

I think the latter model is what this I-D (and anil-bla) are trying to
implement, where a DN has multiple "sub-lines", each of which is
assigned to a separate button, but which (other than by UAs with
appearances for that DN) are not individually addressible.

Dale

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

---

From: "Jerry Yin" <[email-masked]>
Date: Mon, 2 Apr 2007 17:11:30 -0400

Please see in-line comments.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, April 02, 2007 4:40 PM
> To: [email-masked]
> Subject: Re: [BLISS] comments on draft-johnston-bliss-mla-req-00.txt
>
>

Both Broadsoft and Sylantro softswithes support the latter concept. Each UA
should support multiple AORs which represent different Lines. Each Line
(AOR) supports multiple calls (or call appearances). The call appearances
are addressed by indexes starting from 0 to N (N is usually less than 10).
Each appearance is assigned to a soft-key or hard key. The individually
appearance is addressable in terms of making calls or pick up a remote held
call, since you can identify the call by the call index. But for incoming
calls, usually it takes any free call appearance (or index).

Jerry

---

From: "Geoff Devine" <[email-masked]>
Date: Tue, 3 Apr 2007 14:47:45 -0400

Hi Dale,

OK.  ...but that's not how a legacy 1A2 Key System worked back in the
dark ages.  You could always layer hunting on top of it back at the
central office but the original key system implementation had a copper
pair with an E.164 number per line button.  I think it's important to
capture this 1-1 behavior as a baseline function in the mla-req so any
protocol design considers the case.

There are then _many_ enhancements and options you can layer on top of
the baseline.  The 'sub-lines' behavior where a call can hunt to another
idle line appearance is one possibility.

I'd point out that in a true legacy key system, those 'sub-lines' were
indeed individually addressable since they mapped onto a copper pair
with a unique DN.  That DN needed to be individually addressable to make
test calls, if nothing else.  In a PBX with Direct Inward Dial or
Primary Rate you could make this arrangement logical but not in a true
key system with ground start or loop start interfaces.

Geoff

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, April 02, 2007 4:40 PM
To: [email-masked]
Subject: Re: [BLISS] comments on draft-johnston-bliss-mla-req-00.txt

Dale

---

From: [email-masked]
Date: Tue, 3 Apr 2007 21:29:19 -0400

with a unique DN.

Uh, yes, that's what I said, "In the machinery, each line appearance
button corresponds to one DN.  But *as users think about it*..."

Dale

---

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

Geoff,

Thanks for your comments. See mine below.

Thanks,
Alan

Geoff Devine wrote:
>
> 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.
>

Can you explain a little more what you are looking for? The group will 
know whatever status the UA publishes to the Appearance Agent. Perhaps 
this requirement could be met by allowing a UA to not publish certain 
call state information if it wants to keep it private.

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

Any request for bridging or pickup can be rejected by the UAS or even a 
proxy server. Perhaps you just want this called out?

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

Perhaps this requirement needs to be reworded - it is about auto 
discovery. The mechanism should not require that a UA be provisioned 
with the URIs of the other UAs in the group.

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

Are you OK with Dale's suggestion to reword to say that the mechanism 
should cause traffic to scale linearly?

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

You are correct, we could just use an appearance label instead of a 
number. However, ordering of appearances is a very important user 
interface issue. If my application uses appearances "xd3", "k3s", and 
"82s" what would be the order of rendering if my UI only has a row of 
buttons?

Is your requirement for a human-friendly label for the appearances? If 
so, we could add this in addition to the appearance number.

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

That is one way to utilize the appearance number but not the only way. 
Could you help rephrase so that it doesn't imply hunting to you?

> Best regards,
>
> Geoff
>
> ------------------------------------------------------------------------
>