Subject: RE: [Sipping] Comments on BLA draft

From: "Christian Stredicke" <[email-masked]>
Date: Thu, 4 Aug 2005 11:33:47 +0200

Paul, I am on your side. VoIP should be much more cool than the old
stuff.

However, it should be *also* able to emulate the LED blinking behavior
that millions of people use everyday in their office to get their hard
job done. Once they discover there is something better, they will sure
use it.

I think the BLA draft is a pragmatic approach to solve this problem. We
should support it to get the foot into the door of those customers that
are willing to pay good money for a working SIP enterprise system.

CS

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, August 04, 2005 11:01 AM
> To: Christian Stredicke
> Cc: Sipping (E-mail); Venkatesh
> Subject: Re: [Sipping] Comments on BLA draft
> 
> 
> 
> Christian Stredicke wrote:
> > Paul, we are talking here about emulation of legacy stuff... People 
> > simply want to see LED blinking in the same way they did it 
> with their 
> > good old PBX. The "line" is used to identify the LED or 
> button on the 
> > phone that should start blinking.
> > 
> > As far as I understood it.-)
> 
> I note the -)
> 
> I see some similarity here between this draft and the TISPAN 
> requirements draft. Namely that we go to a lot of trouble to 
> emulate behavior that is largely justified by historical 
> legacy rather than current utility.
> 
> Personally, in a shiny new VoIP office telephony system 
> (which I prefer to *not* call a PBX) I would much prefer to 
> have status info displayed for each active call. Then you can 
> yell that you want me to pick up the call with Joe or the 
> call with Sam.
> 
> The association with "lines" is just historical baggage. If 
> you insist in associating with lines, It should be possible 
> to define a mapping that can be done independently in each UA 
> simply by hashing some of the call state data.
> 
> 	Paul
> 
> > CS
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked]
> >>[mailto:[email-masked]] On Behalf Of Paul Kyzivat
> >>Sent: Wednesday, August 03, 2005 10:17 AM
> >>To: Venkatesh
> >>Cc: Sipping (E-mail)
> >>Subject: Re: [Sipping] Comments on BLA draft
> >>
> >>
> >>
> >>Venkatesh wrote:
> >>
> >>>As the name suggests, the feature is all about 'sharing' a 
> >>>resource/line across multiple users. The draft does not impose any 
> >>>limit on the number of simultaneous outgoing calls a UA can
> >>
> >>place. It
> >>
> >>>only proposes to associate each of these calls with a
> >>
> >>unique line id. 
> >>
> >>>There is a section in the draft that talks about multiple
> >>
> >>UAC's trying
> >>
> >>>to use the same line ID simultaneously and how the same could be 
> >>>resolved. Dale's suggestion is an alternate approach to
> >>
> >>solve the same.
> >>
> >>Why is it necessary to have a line id at all? As long as existing 
> >>calls in progress can be seen from different devices the 
> concept of a 
> >>line seems unnecessary. Then there is no reason to seize a 
> line. The 
> >>existing calls can be mapped onto the UI of each device in any way 
> >>that works for the capabilities of the device.
> >>
> >>	Paul
> >>
> >>_______________________________________________
> >>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> >>This list is for NEW development of the application of SIP Use 
> >>[email-masked] for questions on current sip Use 
> >>[email-masked] for new developments of core SIP
> >>
> >>
> >>
> > 
> > 
> 
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 4 Aug 2005 15:52:14 -0400

> From: Christian Stredicke
>

> From: Paul Kyzivat
> requirements draft. Namely that we go to a lot of trouble to emulate
> behavior that is largely justified by historical legacy rather than
> current utility.

It might be baggage, but then again, it might not.  To be usable, systems
have to satisfy a lot of user needs, some of which aren't obvious until one
has tested a candidate system in the field.  (Remember the adage "Never buy
version 1.0!")  A system that has been used in the field for decades may be
suboptimal, but we know that it is *acceptable* to the users, wherease a
new, improved way of doing the same thing might have deficiencies that we
wouldn't spot until deployment.

In this case, it seems to me that the best strategy is to simulate the
legacy systems and allow evolution to improve the deployed solutions, rather
than assuming that we can guess what is better.  (This really is a current
market need for small office PBXs.)

In regard to identifying and displaying call information, it would seem that
having the PBX assign small integers is less useful than displaying To/From
dialog information.  But there have been perennial problems with "what data
items are needed to identify the dialog/subscription/fork", and there may be
pitfalls that would take some time to discover.  And there is still the
convenience (and noise-resistance!) of shouting "Joe, pick up on line five!"

> From: Jeroen van Bemmel
>
> OK, so how about postponing the allocation of a line ID until the moment
> that the user wants to put the call on hold? That way you don't
> unnecessarily restrict the number of simultaneous outgoing calls, just the
> number that can be put on hold simultaneously

Yes, I suppose we could do that.  Though in practice, it seems that "running
out of lines" rarely happens, so it doesn't seem like all that much is
gained.

> Actually, what I was "getting hung up on", is the idea that the user needs
> to select the sub-line ID *before he can start making an outgoing call*.

But the *user* doesn't need to select the ID, only the UA.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 5 Aug 2005 00:09:12 +0200

Dale,

Just out of interested: how big are the BLA groups we're talking about? how 
many lines does a typical system support, and how many buttons does the 
interface have?

Does it mean that if one phone in the BLA group e.g. only has 4 buttons for 
lines, the whole group is restricted to at most 4 simultaneous calls, both 
incoming and outgoing? So in other words, if I want to set up a call center 
with 200 lines I'd need a different solution / draft ?

About the ability to 'grab a line' either before making a call or before 
needing to do a handover: this could easily be made configurable on the 
client, such that the system could do both, right? Just need to make sure 
then that the use case is also reflected in the BLA draft, and that the 
mechanisms used work either before or during a call

Regards,

Jeroen

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 4 Aug 2005 19:11:03 -0400

> From: Jeroen van Bemmel [mailto:[email-masked]]
>

My impression is that historically these systems have two to six lines --
usually about the same number as their are users of the system.  Beyond
that, the "buttons and lights" interface becomes unworkable.

> So in other words, if I want to set up a call center
> with 200 lines I'd need a different solution / draft?

Yes, anything that large would almost certainly want a different (and more
complex) interface.

> incoming and outgoing?

Pretty much of necessity, all of the instruments that participate in a BLA
group would have to agree on the number of lines in the group.  I suppose
there's no real necessity for it, but otherwise some of the instruments
would not be able to access calls on the highest-numbered lines.

> mechanisms used work either before or during a call

There's no logical impossibility with assigning a line to a call after it is
established.  I've doubted its usefulness, and it somewhat increases the
conceptual complexity of the interface.  It does, I think, require a
somewhat more complex state agent, as the state agent has to "adopt" a
dialog that is in progress, rather than one that is being established, but I
might be wrong about that.

Dale