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 protected]] > Sent: Friday, April 24, 2009 08:40 > To: Orton, Scott (RICH1:B620) > Cc: [email protected]; 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 <[email protected]>: > > 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 > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
