[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] Comments on BLA draft
Jeroen,
Comments in-line, below.
Paul.
> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmel at zonnet.nl]
> Sent: Wednesday, August 03, 2005 6:25 PM
> To: Paul Pepper; Paul Kyzivat; Venkatesh
> Cc: Sipping (E-mail)
> Subject: Re: [Sipping] Comments on BLA draft
<snip/>
> For the originating use case in your George and Mildred
> story, suppose both
> are line-sharing helpdesk at example.com do you agree that both
> should be able
> to originate as many calls as they like, simultaneously, assuming the
> identity of helpdesk at example.com?
[paul]
No. There are physical user agent devices, that I and others have to
work with, whose user interface limits the number of lines and calls
that can be presented to the user.
> And maybe for the call-pickup feature, would it be sufficient
> to request a
> shared line (a button) the moment Mildred wants to do a
> handover, instead of
> before making her call?
[paul]
Well, that is one way of doing it. However, we need a solution given the
user agent restrictions described above, and given the expectation that
hold operations succeed. This requires that we guarantee the resource
(shared line) is reserved when the call is made and not when the call is
placed on hold.
I think the underlying mechanisms of the dialog event package allows for
a variety of shared line solutions. Each of us has to make different
trade-offs. The BLA draft adapts the dialog event package to encompass
the trade-offs that some of us have to make, in my case the limited user
interface. If we can accept that then even those of us hunched over with
the historical baggage that we have to carry can be accommodated :-)
> Jeroen
>
> ----- Original Message -----
> From: "Paul Pepper" <paul.pepper at citel.com>
> To: "Jeroen van Bemmel" <jbemmel at zonnet.nl>; "Paul Kyzivat"
> <pkyzivat at cisco.com>; "Venkatesh" <vvenkatar at gmail.com>
> Cc: "Sipping (E-mail)" <sipping at ietf.org>
> Sent: Wednesday, August 03, 2005 5:43 PM
> Subject: RE: [Sipping] Comments on BLA draft
>
>
> Jeroen,
>
> I agree that the scenario I described can be broken down in to the two
> requirements you mention. The usecase and example that I gave
> represent
> the way many people work. If Mildred doesn't know where
> George is in the
> office then she probably would not know which extension the
> call should
> be transferred to, so your alternate way of using transfer to
> solve the
> problem wouldn't work (in this situation, at least). The best
> option in
> this case would be to place the call on hold, and somehow tell George
> (maybe by paging him) that he must retrieve the held call from the
> telephone nearest to him.
>
> If we accept that people may work in this way, as they will
> when old PBX
> technology and SIP technology are mixed, then both
> requirements need to
> be solved.
>
> Paul.
>
> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmel at zonnet.nl]
> Sent: Wednesday, August 03, 2005 12:55 PM
> To: Paul Pepper; Paul Kyzivat; Venkatesh
> Cc: Sipping (E-mail)
> Subject: Re: [Sipping] Comments on BLA draft
>
>
> Paul,
>
> The scenario you describe below is mixing two distinct requirements:
> 1 - the ability to present the status of a line to all users
> consistently
> 2 - the ability to pass calls between users (possibly
> restricted within
> some
> administrative group)
>
> (2) could be addressed in a number of ways using existing mechanisms.
> Mildred telling George that he can retrieve the call from
> line 3 (using
> some
> out-of-band mechanism, e.g. shouting to him) introduces the
> concept of a
>
> 'line' to give both a common means to refer to the call (presumably so
> George knows what button to press), but wouldn't it be much simpler if
> Mildred would simply transfer the call to George directly?
>
> If the concept of a 'line' is only needed to synchronize between users
> in a
> support group and is in fact used to refer to a particular call to be
> transfered, it sounds more like an user interface issue (how
> to present
> this
> to the user such that he/she understands what's going on). It could be
> that
> typical current users are used to the concept of a shared line, making
> it a
> suitable abstraction for presentation. But then the notion of
> 'grabbing
> a
> line' takes this concept too far, as - like I argued before -
> it puts an
>
> artifical restriction where there's really no need.
>
> I think this entire discussion occurs because explicit
> requirements are
> missing in the draft. To start with, requirement (1) as I put it above
> could
> be restated as a true requirement, not including the mechanism /
> selected
> solution (the concept of a shared line).
>
> The concept of a 'line' is commonly used in telephony systems, but I
> think
> within the context of SIP usually more as a metaphore than as
> a physical
>
> entity. Metaphores for user interface presentation are fine and
> definitely
> needed (minimize cognitive load, etc), no argument there. However,
> metaphores introduced as requirements that put artificial
> limitations on
> the
> system is taking it one step too far, IMO
>
> Regards,
>
> jeroen
>
> ----- Original Message -----
> From: "Paul Pepper" <paul.pepper at citel.com>
> To: "Paul Kyzivat" <pkyzivat at cisco.com>; "Venkatesh"
> <vvenkatar at gmail.com>
> Cc: "Sipping (E-mail)" <sipping at ietf.org>
> Sent: Wednesday, August 03, 2005 12:41 PM
> Subject: RE: [Sipping] Comments on BLA draft
>
>
> I believe there is a real-world requirement for identifying multiple
> instances of a shared line. In an office situation, say, there will be
> groups of users with several instances of the same shared line (e.g.
> sip:support at example.com). To allow calls to be passed around within a
> group of users there must be a way of identifying which instance of a
> shared line a call is placed on. But accurate identification of shared
> line instances requires that those lines be presented to the user in a
> uniform and coherent manner. This is where the line index comes in.
>
> As an example, say George and Mildred work amongst a group of support
> staff at example.com. Both have user agents with five or more
> instances
> of the same shared line, sip:support at example.com, as do their
> colleagues. Users in this support group can pick up any call coming in
> to sip:support at example.com. When an incoming call is answered, the
> shared line instance carrying the call is shown on all user
> agents in a
> consistent way. So, if Mildred picks up a call on shared line index 3,
> she can place the call on hold and tell George that he can
> retrieve the
> call from line index 3 of sip:support at example.com.
>
> For this call retrieval to be possible, all user agents must list all
> the calls in the group in a consistent manner. They do this by using
> the line index to control which line instances the calls appear on.
>
> Paul.
>
>
> -----Original Message-----
> From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Wednesday, August 03, 2005 9:14 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP