Subject: RE: [BLISS] Call Park/Retrieve

From: "Kucmerowski, Dennis \(Com US\)" <[email-masked]>
Date: Mon, 26 Feb 2007 14:17:04 -0800

Michael,

The Park to orbit (aka. park to server or park to system) whereby the
User must input a orbit number is old feature operation which may result
in the user entering an already used orbit. This form of Park to server
is somewhat limited.

Enhanced feature Park to Server operation should allow the user to
request the server to park a call and the server should allocate the
first available park orbit.  The response could be given to the user in
two forms: announcement and additional information i.e.., park orbit
number given back to the end user. 

Both Old and Enhanced may require a bit different implementation e.g.,
if park orbit not given then selects the first orbit or if park orbit
given, attempt to park in the requested orbit. 

For Call Retrieve the orbit must be specified.

I did not see a Recall from park, whereby the Park exceeds a given time
and will attempt to notify or redistribute the parked party back to the
UA that parked the call to the server. In the case of redistributing the
parked party back to the UA, it would be nice for the UA to know the
call coming back was a parked call and not a new incoming call.  Is
recall from park in the plans?

The old park to server feature whereby the user enters a park
destination is more in tune with the Park to Subscriber feature.  In
this case one UA parks the call to another UI by indicating park to
subscriber and the destination to be parked-to (not orbit).

Best Regards,
 
Dennis L. Kucmerowski 

561-923-1703
Systems Engineering

-----Original Message-----
From: Michael Procter [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 6:03 AM
To: [email-masked]
Subject: [BLISS] Call Park/Retrieve

I have just submitted an Internet-Draft concerning call park/retrieve.
It is actually a draft I wrote almost 3 years ago, but which sank
without trace.  Given the BLISS charter, I think that it may be time to
revisit it.

Until it appears, you can see the original one at:
http://tools.ietf.org/html/draft-procter-sipping-call-park-extension-00
(The new version only updates the dates and references and the like).

The draft documents a real problem associated with parking calls in a
multi-vendor environment.  The solution is based upon the
service-examples document and is workable, although refinements are
clearly possible.

I'd be interested to hear comments on the draft, both the scope of the
problem and the approach taken.  I'd also be interested in how other
people have solved this problem, or even if they have avoided it
entirely.

Regards,

Michael Procter

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: [email-masked]
Date: Tue, 27 Feb 2007 10:56:47 -0500

From: "Kucmerowski, Dennis \(Com US\)" <[email-masked]>

Do you know of any implementations of this scheme?

Dale

---

From: "Michael Procter" <[email-masked]>
Date: Tue, 27 Feb 2007 08:28:04 -0800

Dennis,

Thanks for your comments.  My responses are inline.

> in the user entering an already used orbit. This form of Park to
server

I agree that the model is not new.  This isn't necessarily bad, in my
opinion.  And whilst the selected orbit might be in use, this is not
necessarily a limitation.  A Park Server may choose to accept multiple
calls and form a queue.  This is an implementation issue and not a
protocol issue though.

> number given back to the end user.

Yes, this is the other normal model.  I discuss this briefly in section
4, except I don't mention announcements.  Further elaboration could be
added.

> given, attempt to park in the requested orbit.

Both these approaches are possible, and could be implemented by
combining the approaches taken in sections 2 and 4.  In this scenario,
the initial orbit given in the REFER request-uri might be considered
'advisory' until a confirmed one was returned by the Park Server.

> recall from park in the plans?

My draft initially began as a way to resolve the apparent (in my
opinion) weakness in addressing associated with the service-examples
park/retrieve approach.  There are plenty of other areas surrounding
park/retrieve that could be addressed with a view to standardising them
somewhat, and I think that this forum is probably the best place to
discuss what needs attention and what can be left as implementation
defined.

> subscriber and the destination to be parked-to (not orbit).

That is certainly one implementation that I have seen.  Parking against
a subscriber is not always appropriate though, especially when the
ultimate destination UA is not known when parking.

One thing that is clear is that people have different expectations of a
park/retrieve service.  Any attempt to codify one set of implementation
choices is likely to be counter-productive.  Instead, we need to
identify the missing building blocks that can be used in multiple ways
whilst still offering some level of interoperability between vendors.

Regards,

Michael Procter