Subject: RE: [Sipping] Comments on BLA draft

From: "Paul Pepper" <[email-masked]>
Date: Wed, 3 Aug 2005 16:43:14 +0100

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:[email-masked]] 
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" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>; "Venkatesh"
<[email-masked]>
Cc: "Sipping (E-mail)" <[email-masked]>
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:[email-masked]). 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:[email-masked], as do their
colleagues. Users in this support group can pick up any call coming in
to sip:[email-masked]. 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:[email-masked].

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: [email-masked] [mailto:[email-masked]] 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 [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 

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 3 Aug 2005 19:25:15 +0200

Paul,

"Mildred doesn't know where George is in the office"... sounds like a SIMPLE 
issue to me :)

Anyway, I see a mix of approaches: some enable people to do things in the 
way they were used to in the pre-SIP era, and some create new ways of doing 
things. Both can be valuable, and sometimes even complementary.

I believe we can find a way to make some lights blink on SIP-based 
telephones, such that people can answer a particular "line", put it on hold 
and yell to the next guy to pick it up. I accept requirements on user 
experience (in fact, for me they should be at the top of the list) such as 
"this feature should appear to work similar to the way things work with a 
PBX system". However, as we "port" old features to this new technology we 
need to make sure not to pick the ones that impose unnecessary restrictions.

For the originating use case in your George and Mildred story, suppose both 
are line-sharing [email-masked] do you agree that both should be able 
to originate as many calls as they like, simultaneously, assuming the 
identity of [email-masked]?

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?

Jeroen

----- Original Message ----- 
From: "Paul Pepper" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>; "Paul Kyzivat" 
<[email-masked]>; "Venkatesh" <[email-masked]>
Cc: "Sipping (E-mail)" <[email-masked]>
Sent: Wednesday, August 03, 2005 5:43 PM
Subject: RE: [Sipping] Comments on BLA draft

Jeroen,

Paul.

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]]
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,

Regards,

jeroen

----- Original Message ----- 
From: "Paul Pepper" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>; "Venkatesh"
<[email-masked]>

Paul.

-----Original Message-----

resource/line
number
section
line
suggestion

Paul