Subject: [BLISS] Review draft-procter-bliss-call-park-extension-00

From: "Willekens, Marc" <[email-masked]>
Date: Sun, 8 Jul 2007 11:08:22 +0200

Hi Michael;
 
My first impression of your idea was: it's good to provide some
backwards compatibility with some legacy equipment, and give the
end-user an already known kind of interface. But the main question is:
is this the way to go? Is this good or bad for the further evolution of
SIP? 
 
The draft directly proposes a certain solution without considering the
different possible use cases and the different new capabilities offered
by SIP phones. It only gives a proposal based on the traditional
implementation of this feature.

In this draft, first the method is given for the "orbit number"
allocated by the user who wants to park the call. However, later in the
document the disadvantage of this method is indicated and a proposal is
given to have the allocation of the orbit number done by the park
server.

Further, the draft only considers the case of a REFER method passed to
the park server. In the BLISS at IETF.68 however, the problem space for
interoperability with call park was indicated as different possible
choices in implementing this feature related to the chosen methods such
as:

- use of REFER to the caller
- use of REFER to the Park server
- use of KPML (keypad markup language) approach

It was already indicated that the end-device should be able to handle
the REFER method for the park feature to allow the interworking between
the equipment of different vendors.

The draft only proposes a solution towards the traditional closed PABX
model and as such does not fullfil the goal of the BLISS and the
evolutional approach of the SIP.

Further, the document does not handle the situation for a parked call
which is not retrieved: will the call be destroyed, returned to the
original party who did the park, ....

If we really want to solve the interoperability between SIP UA and
servers, then the handling of the feature should be clearly defined from
the SIP paradigma without being based too much on the classical PABX
paradigm. Else, we will always be locked to different kind of
proprietary solutions. 

Some questions to think about:

1. Why should an end-user be bothered with these park or orbit short
numbers? Is it not better to have a system which supports the end-user
in a much better way? When you have calls parked to your identity and
waiting in a queue, why do we then need short numbers? Is it not enough
to pick-up any SIP phone and enter your PIN code to inform the system
where you are and then the system can indicate the parked calls in
another more appropriate way.

2. There is certainly a need for the call park/retrieve feature. Many
customers are still requesting it for reasons of cost reduction in their
telephony systems. E.g. workers in a logistic environment with a high
mobile profile but without mobile end devices (for cost reductions) and
a low called profile can benefit from the call park feature. The amount
of end devices can be limited, and any end-device can be used to
retrieve a parked call for and by a certain employee. When the amount of
end-devices is limited, why not offereing more flexibility in that
end-device related to the traditional PABX phones?

3. In other business environments, when users have mobile end devices,
the need for the call park/retrieve feature can disappear. E.g. this is
the case in business environments which first had fixed phones and when
an employee wanted to handle a call at his desk further at another
location. With a mobile device, the call park feature no longer makes
sense.

4. The handling of parked calls can also be different in IP networks as
for TDM networks. In a TDM network, there was always the cost for the
setup of a call and for the duration of a call. For an IP network, the
amount of parked calls and the duration of the parking can be much
higher. This requires another kind of user interface.

With best regards,
Marc.

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

---

From: "Michael Procter" <[email-masked]>
Date: Tue, 10 Jul 2007 02:25:27 -0700

Hi Marc,

Thanks for taking the time to read my draft and comment on it.  Before I
respond to each point, I think it might be helpful to provide a little
background.  This draft was first written over three years ago, and only
recently re-issued under BLISS, with minimal changes.

The key aim of the draft is not to try to standardise the parking
service - that would have been a step too far three years ago, and even
now we steer away from phrases such as 'standardising a feature'.

Instead, the draft sought to highlight an area of interoperability that
has already led to multiple incompatible implementations.  The problem
basically boils down to one of identification.  How should you identify
parked calls?  The IETF example flow
(draft-ietf-sipping-service-examples-12, sec 2.15) relies on the dialog
identifier of the parked call, to subsequently identify the call for
retrieval.  This is an excellent approach, except when you need to pass
the identifier by non-electronic means, such as passing a written note.
My draft describes a simple change to support this common way of
working, by allowing a human-friendly label to be attached to a parked
call.

> My first impression of your idea was: it's good to provide some
backwards
> compatibility with some legacy equipment, and give the end-user an
already
> known kind of interface. But the main question is: is this the way to
go?
> Is this good or bad for the further evolution of SIP? 

I'm not sure exactly what you are referring to here.  If you are asking
whether call park is something that SIP should support (as some of your
later comments seem to suggest), then I think the answer is clearly yes.

If you are asking whether a human-usable identifier for parked calls is
a good or bad thing, then I believe that the answer is that it is a good
thing.  Existing users expect a model of this sort. Even if more
sophisticated models might exist in the future, users want to be able to
park (and retrieve) calls today.

> different possible use cases and the different new capabilities
offered by
> SIP phones. It only gives a proposal based on the traditional

Yes.  The motivation for this is described in the Overview.  It seeks to
address a specific collection of use cases.  These are relevant both to
legacy phones and to the many already deployed SIP phones that share a
similar form factor.  Not everyone is using fancy videophones with
touch-sensitive screens, or PC-based soft-phones with multi-tabbed user
interfaces!

> In this draft, first the method is given for the "orbit number"
allocated
> by the user who wants to park the call. However, later in the document
the
> disadvantage of this method is indicated and a proposal is given to
have
> the allocation of the orbit number done by the park server.

Yes.  I should spend some time clarifying that.  Each approach has
advantages and disadvantages.  Supporting both simultaneously is not
tricky, and permits multiple ways of working with only policy changes.

> Further, the draft only considers the case of a REFER method passed to
the
> park server. In the BLISS at IETF.68 however, the problem space for
the
> REFER method for the park feature to allow the interworking between
the
> equipment of different vendors.

This draft predates BLISS and IETF68 by some time!

> evolutional approach of the SIP.

Again, this is unsurprising given the history.  This draft is simply one
part of the total solution.

> original party who did the park, ....

These scenarios should all be considered (along with several others)
when designing a parking service.  Some of them may even need some level
of standardisation.  None of them are within the scope of this draft.

> paradigm. Else, we will always be locked to different kind of
proprietary
> solutions. 

I disagree.  Clearly defining the handling of the feature is an approach
that is more likely to stifle innovation.  Instead, we should take the
approach selected for BLISS.  From the BLISS charter:

	The focus will not be on rigorous definition of what the
specific
	feature is and exactly how it works. Rather, the focus will be
on 
	documenting the variations that exist in the wild sharing common

	interop problems, figuring out a minimum baseline requirement
for a UA 
	and servers(minimum set of primitives etc.), defining minimum
levels 
	of functionality and functional primitives required to realize a
broad 
	class of related features, and on interoperating with other
elements 
	which might implement one of those features in different ways.

> numbers? Is it not better to have a system which supports the end-user
in
> a much better way? When you have calls parked to your identity and
waiting
> in a queue, why do we then need short numbers? Is it not enough to
pick-up
> any SIP phone and enter your PIN code to inform the system where you
are
> and then the system can indicate the parked calls in another more
> appropriate way.

Your last sentence describes one of several traditional parking
implementations, and can be achieved by using the technique proposed in
my draft.  The significance of the orbit is defined by policy not
protocol, which means you can design systems such as the one you outline
as well as several other variations without changing the equipment used
(apart from configuring the policy in your park server, presumably).

I am not suggesting that the approach outlined in my draft is the best
approach, or indeed the only approach.  The draft describes what strikes
me as the simplest approach consistent with catering to the variations I
had in mind.

> mobile profile but without mobile end devices (for cost reductions)
and a
> low called profile can benefit from the call park feature. The amount
of
> end devices can be limited, and any end-device can be used to retrieve
a
> parked call for and by a certain employee. When the amount of
end-devices
> is limited, why not offereing more flexibility in that end-device
related
> to the traditional PABX phones?

I'm not sure what your question means.  Can you clarify please?

> 3. In other business environments, when users have mobile end devices,
the
> need for the call park/retrieve feature can disappear. E.g. this is
the
> case in business environments which first had fixed phones and when an
> employee wanted to handle a call at his desk further at another
location.
> With a mobile device, the call park feature no longer makes sense.

I disagree.  Parking is still a useful feature with mobile devices -
sometimes even more so (although then it can start to merge with other
advanced call handling features such as line sharing).

> amount of parked calls and the duration of the parking can be much
higher.
> This requires another kind of user interface.

I am not sure what you are suggesting here.  If you are suggesting that
different underlying technologies (TDM and SIP) require different user
interfaces, then I disagree.  If instead, you are suggesting that
different underlying technologies may promote different usage patterns,
which in turn may lead to more useful user interfaces being developed,
then I agree.  Nothing in my draft precludes such developments.

If I decide to reissue this draft, then I will certainly bear your
comments in mind during the rewrite.  There is clearly much more that I
can say to explain what I am trying to achieve.

Regards,

Michael