Subject: [BLISS] Comments on draft-procter-bliss-call-park-extension-04 (AutoRetrieve proposal)

From: "Scott Orton" <[email-masked]>
Date: Fri, 24 Apr 2009 09:20:21 -0500

Michael,
   I am breaking my comments up into several threads so they are easier
to follow. 

I would like to add the ability to specify an auto-retrieve timer value
both in the park request and by policy on the call park server. This
could be accomplished by adding a new autoretrieve tag to the url. The
value of the tag would be 1*digit and contain the time in seconds until
the parked call is sent back to the user that parked the call. 

This ability is useful in implementations of devices like attendant
consoles where the console parks the call and if no one picks the call
up it is not lost in limbo and comes back to the parking UA after some
defined duration. 

When the timer expired I could see two ways to get the call back to the
parking UA. The first would be to send a refer to the parked call
redirecting them to the URL of the parking party. The second would be
that the callparkserver could use a third party call control type
functionality and extend an invite to the parking user. The later case
is more complicated due to the media negotation issues but I would allow
both. 

Scott

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 24 Apr 2009 10:08:24 -0500

It's also used extensively in Retail and other verticals to avoid being
locked into "Call Park jail".

You'll notice when you call into a store, they park you while they serve
another customer, and then magically you get retrieved after a minute or
so, often by a different sales clerk.

I think we should also suggest a default timer of 60s.

> _____________________________________________ 
> From: 	Orton, Scott (RICH1:B620)  
> Sent:	Friday, April 24, 2009 07:20
> To:	[email-masked]'; [email-masked]'
> Cc:	Audet, Francois (SC100:3055); Worley, Dale (BL60:9D30)
> Subject:	Comments on draft-procter-bliss-call-park-extension-04
> (AutoRetrieve proposal)
> 
> Michael,
>    I am breaking my comments up into several threads so they are
> easier to follow. 
> 
> I would like to add the ability to specify an auto-retrieve timer
> value both in the park request and by policy on the call park server.
> This could be accomplished by adding a new autoretrieve tag to the
> url. The value of the tag would be 1*digit and contain the time in
> seconds until the parked call is sent back to the user that parked the
> call. 
> 
> When the timer expired I could see two ways to get the call back to
> the parking UA. The first would be to send a refer to the parked call
> is more complicated due to the media negotation issues but I would
> allow both. 
> 
> Scott
> 
> 
>

---

From: Michael Procter <[email-masked]>
Date: Fri, 24 Apr 2009 16:46:04 +0100

Hi Scott,

2009/4/24 Scott Orton <[email-masked]>:
> I would like to add the ability to specify an auto-retrieve timer value both
> in the park request and by policy on the call park server. This could be
> accomplished by adding a new autoretrieve tag to the url. The value of the
> tag would be 1*digit and contain the time in seconds until the parked call
> is sent back to the user that parked the call.

I can certainly see merit in a park server implementing a policy like
this, but I am not sure we need to define anything at the protocol
level.  In particular, I don't see a particularly strong reason to
allow the parking UA to set (or even merely suggest) how long the call
should be parked for.  That strikes me as something that can and
should be handled by the park server.

Regards,

Michael

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 24 Apr 2009 10:50:38 -0500

On the firest part, you are correct, it's not new protocol.

But a default timer, and a paragraph on Auto-Retrieve is
exactly the type of information that is appropriate for
an INFORMATIONAL draft.

Introducing phones that don't have an Auto-retrieve feature
for call park will cause significant headaches in the real world.

> -----Original Message-----
> From: Michael Procter [mailto:[email-masked]] 
> Sent: Friday, April 24, 2009 08:46
> To: Orton, Scott (RICH1:B620)
> Cc: [email-masked]; Audet, Francois (SC100:3055); Worley, 
> Dale (BL60:9D30)
> Subject: Re: Comments on 
> draft-procter-bliss-call-park-extension-04 (AutoRetrieve proposal)
> 
> Hi Scott,
> 
> 
> > seconds until the parked call is sent back to the user that 
> parked the call.
> 
> I can certainly see merit in a park server implementing a 
> policy like this, but I am not sure we need to define 
> anything at the protocol level.  In particular, I don't see a 
> particularly strong reason to allow the parking UA to set (or 
> even merely suggest) how long the call should be parked for.  
> That strikes me as something that can and should be handled 
> by the park server.
> 
> Regards,
> 
> Michael
>

---

From: "Scott Orton" <[email-masked]>
Date: Fri, 24 Apr 2009 11:07:22 -0500

The reason I suggest that a client be able to specify the duration in
the park request is that you may have a client implementing a service
where it may want to override the duration of the default timer on the
call park server. 

Scott 

-----Original Message-----
From: Audet, Francois (SC100:3055) 
Sent: Friday, April 24, 2009 10:51 AM
To: Michael Procter; Orton, Scott (RICH1:B620)
Cc: [email-masked]; Worley, Dale (BL60:9D30)
Subject: RE: Comments on draft-procter-bliss-call-park-extension-04
(AutoRetrieve proposal)

But a default timer, and a paragraph on Auto-Retrieve is exactly the
type of information that is appropriate for an INFORMATIONAL draft.

Introducing phones that don't have an Auto-retrieve feature for call
park will cause significant headaches in the real world.

> Cc: [email-masked]; Audet, Francois (SC100:3055); Worley, Dale 
> (BL60:9D30)
> Subject: Re: Comments on

> should be parked for.
> That strikes me as something that can and should be handled by the 
> park server.
> 
> Regards,
> 
> Michael
>

---

From: Michael Procter <[email-masked]>
Date: Sat, 25 Apr 2009 07:29:53 +0100

> for call park will cause significant headaches in the real world.

What, exactly, does a phone have to do to have an 'Auto-retrieve'
feature?  As far as I can tell, all the service policy you have
described so far is for the park server, not the phone.

Michael

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 27 Apr 2009 15:36:58 +0100

Hi,

I think the auto-retrieve timer is really something that would be
implemented in the park server and the phone does not need to know
anything about it.

What might be useful from the parking UA's perspective is that when the
call is auto-retrieved (i.e. the park server refer's the call back to
the parking UA or possibly a different UA) that the resulting INVITE
contains an indication that the INVITE is a result of the auto-retrieve
initiated by the park server. Could we say something about this in the
draft?

Regards
Andy

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Michael Procter
>Sent: 25 April 2009 07:30
>To: Francois Audet
>Cc: [email-masked]; Scott Orton
>Subject: Re: [BLISS] Comments on 
>draft-procter-bliss-call-park-extension-04(AutoRetrieve proposal)
>
>_______________________________________________
>BLISS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/bliss
>

---

From: Michael Procter <[email-masked]>
Date: Mon, 27 Apr 2009 18:11:20 +0100

> implemented in the park server and the phone does not need to know

Yes, that was my thought.

> initiated by the park server. Could we say something about this in the

Surely this is something that could be addressed with History-Info?

Michael

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 27 Apr 2009 12:36:32 -0500

Actually, I don't think it would be History-Info: I think it would
be Referred-by header (RFC 3892). It would just say it's the
Park Server. 

> Sent: Monday, April 27, 2009 10:11
> To: Hutton, Andrew
> Cc: Audet, Francois (SC100:3055); [email-masked]; Orton, 
> Scott (RICH1:B620)
> > What might be useful from the parking UA's perspective is that when 
> > the call is auto-retrieved (i.e. the park server refer's 
> the call back 
> > to the parking UA or possibly a different UA) that the resulting 
> > INVITE contains an indication that the INVITE is a result of the 
> > auto-retrieve initiated by the park server. Could we say something 
> > about this in the draft?
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 28 Apr 2009 09:38:29 +0100

I agree with Francois it would I assume be the Referred-by header that
contains the URI of the park server and as long as the UA can match this
against it's local configuration then this will be ok.

I do think we should have a short description of the auto-retrieve
procedure including an example message flow in the draft.

Andy

>From: Francois Audet [mailto:[email-masked]] 
>Sent: 27 April 2009 18:37
>To: Michael Procter; Hutton, Andrew
>Subject: RE: [BLISS] Comments on

---

From: Michael Procter <[email-masked]>
Date: Tue, 28 Apr 2009 10:00:10 +0100

> against it's local configuration then this will be ok.

That would probably be more straightforward.  But it assumes a
particular way of achieving the feature.

> procedure including an example message flow in the draft.

I'm still not entirely convinced that it belongs in this draft,
although I agree it is an important aspect to consider in an
implementation.  I'm also not sure that it is within scope for BLISS,
given that it does seem to be trying to standardise a feature over and
above the level needed for 'basic interoperability'.

However, I am open to persuasion!  To that end, I'd appreciate
contributions of text / message flows.

Michael

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 28 Apr 2009 10:13:06 -0500

Basically, I think a CallPark without an autoretrieve is
effectively an "unsafe" feature, since it will result in
users (typically customers) to wait forever in the 
parking space. 

> Sent: Tuesday, April 28, 2009 02:00
> To: Hutton, Andrew
> > contains the URI of the park server and as long as the UA can match 
> > this against it's local configuration then this will be ok.
> 
> That would probably be more straightforward.  But it assumes 
> a particular way of achieving the feature.
> 
> I'm still not entirely convinced that it belongs in this 
> draft, although I agree it is an important aspect to consider 
> in an implementation.  I'm also not sure that it is within 
> scope for BLISS, given that it does seem to be trying to 
> standardise a feature over and above the level needed for 
> 'basic interoperability'.
> 
> However, I am open to persuasion!  To that end, I'd 
> appreciate contributions of text / message flows.
> 
> Michael
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 29 Apr 2009 14:22:07 +0100

I agree - I would like something to be said about it.

John 

> On Behalf Of Francois Audet
> Sent: 28 April 2009 16:13
> Subject: Re: [BLISS] Comments 
> ondraft-procter-bliss-call-park-extension-04(AutoRetrieve proposal)
>