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 protected]; Worley, Dale (BL60:9D30) Subject: RE: Comments on draft-procter-bliss-call-park-extension-04 (AutoRetrieve proposal) 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 protected]] > Sent: Friday, April 24, 2009 08:46 > 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 (AutoRetrieve proposal) > > Hi Scott, > > > 2009/4/24 Scott Orton <[email protected]>: > > 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 > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
