Subject: [BLISS] Comments on draft-procter-bliss-call-park-extension-04

From: "Scott Orton" <[email-masked]>
Date: Fri, 24 Apr 2009 08:58:14 -0500

Michael,
    I would like to propose that the definition of the orbit be opened
up to allow a sip username to be part of the orbit. Alternatively there
could be an additional parameter added to support a username. What I am
looking for is the ability to park a call against a sipusername rather
than against an orbit. The advantage is that a user can subscribe to the
callpark server against their username and any time a call is parked all
of the clients who have subscribed to the dialog event will be informed
that a call is parked against them.

There are two ways to define the username. One would be to assume that
the domain of the callpark server is the same as the domain of the user.
This is limiting as you could possibly have a callpark server providing
service for multiple domains. The other is to require the users to
specify their domain. Assuming that the orbit is extended I think the
URL would look like the following:

sip:[email-masked];orbit=orton

sip:[email-masked];orbit=orton%40test.com

Scott

---

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

Hi Scott,

Thanks for your comments.

2009/4/24 Scott Orton <[email-masked]>:
> Michael,
>     I would like to propose that the definition of the orbit be opened up to
> allow a sip username to be part of the orbit.

We could made orbit be defined as:
  orbit-value = pvalue

Which I think would give you the flexibility you need without breaking
generic parsers.  I am slightly wary of doing this, since one of the
original motivators for the orbit parameter was to have a simple
identifier that could easily be passed around by humans and entered
with a simple 12-key keypad.

However, if we relaxed the content of the parameter to be more
general, a site that requires digit-only orbits could enforce that at
the park server.  If we go down this route, it is probably worth
highlighting in the text, to ensure park servers consider whether to
offer a 'restrict to digits only' option.

How does that sound?

Michael

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 24 Apr 2009 11:01:35 -0500

Stepping up a level...

What I am noticing is that the challenges in implementing Call Park are different
depending on the context.

In an SME type environement with 12-key phones, the idea of
using digits as the orbit (and having the end user type it to park a call) is
quite appealing.

However, this is a lot less appealing in two scenarios that I can think of:

- When it's not a phone that you are using, but a rich-UI client (say, on 
  a PC for example). In this case, the last thing you want, is the end use
  doing star codes. It just doesn't make any sense.

- In a large service provider network, managing an orbit space seperately from
  the user profile information seems cumbersome.

I completely agree with you that if we can satisfy all those requirements
without requiring complex parsers, it would be much better.

> -----Original Message-----
> From: Michael Procter [mailto:[email-masked]] 
> Sent: Friday, April 24, 2009 08:40
> 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
> 
> Hi Scott,
> 
> > up to allow a sip username to be part of the orbit.
> 
> Which I think would give you the flexibility you need without 
> breaking generic parsers.  I am slightly wary of doing this, 
> since one of the original motivators for the orbit parameter 
> was to have a simple identifier that could easily be passed 
> around by humans and entered with a simple 12-key keypad.
> 
> However, if we relaxed the content of the parameter to be 
> more general, a site that requires digit-only orbits could 
> enforce that at the park server.  If we go down this route, 
> it is probably worth highlighting in the text, to ensure park 
> servers consider whether to offer a 'restrict to digits only' option.
> 
> How does that sound?
> 
> Michael
>

---

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

Francois,
  I think this spells out the differences well. 

If there is a concern on opening up the definition of the orbit then I would recommend that instead of extending the orbit that we add a second parm for parking a call against a user. This would allow the definition of the orbit for the keypad cases and the user case to remain separate.

Separating them may simplify the implementation of the park server. As it would not have to decode the orbit to determine if it was only a digits as the logic for manipulating overlapping orbits will be different from the issues with parking the call against a username. As I can see that the call park server could be provisioned to only allow parking against particular users for security reasons. 

Scott

-----Original Message-----
From: Audet, Francois (SC100:3055) 
Sent: Friday, April 24, 2009 11:02 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

Stepping up a level...

What I am noticing is that the challenges in implementing Call Park are different depending on the context.

In an SME type environement with 12-key phones, the idea of using digits as the orbit (and having the end user type it to park a call) is quite appealing.

I completely agree with you that if we can satisfy all those requirements without requiring complex parsers, it would be much better.

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

---

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

> without requiring complex parsers, it would be much better.

So, would changing orbit-param to be a pvalue rather than 1*DIGIT be
sufficient for you?  If so, and if I hear no dissenting voices, I'm
happy to make that change.

Michael

---

From: "Scott Orton" <[email-masked]>
Date: Mon, 27 Apr 2009 17:16:22 -0500

It works for me to change it to a pvalue.

Scott

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

2009/4/24 Francois Audet <[email-masked]>:
>
> I completely agree with you that if we can satisfy all those 
> requirements without requiring complex parsers, it would be much
better.

Michael