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

["Scott Orton" <[e-mail]>]

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: [e-mail]; 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.

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:[e-mail]]
> Sent: Friday, April 24, 2009 08:40
> To: Orton, Scott (RICH1:B620)
> Cc: [e-mail]; Audet, Francois (SC100:3055); Worley, Dale 
> (BL60:9D30)
> Subject: Re: Comments on draft-procter-bliss-call-park-extension-04
> 
> Hi Scott,
> 
> Thanks for your comments.
> 
> 2009/4/24 Scott Orton <[e-mail]>:
> > 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
>