Subject: [Sipping] Parking and retrieving calls

From: "Michael Procter" <[email-masked]>
Date: Mon, 10 May 2004 09:38:43 +0100

I have been working on a call park/retrieve implementation, based upon the example given in the Service Examples.  In particular, I want to solve the problem of identifying the parked call for retrieval by some mechanism other than the dialog id.

I have written up my ideas in an ID:
http://www.ietf.org/internet-drafts/draft-procter-sipping-call-park-extension-00.txt

Has anyone else tried to solve this problem?  What do people think of this approach?  What changes can be made to make the approach better?

Regards,

Michael Procter

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christian Stredicke" <[email-masked]>
Date: Mon, 10 May 2004 22:48:05 +0200

I think it's a feature to park a call on a specific server; otherwise it
would be difficult to shout through the police department "hey dude, can you
pick up line 2?"

For attendant transfer (currently the only to generate proper music on
hold!) however it does make sense to have a fabric that automatically
allocates a park orbit. But in this case it's possible to pick up exactly
that call again because the user agent has all the information to pick
exactly that call up (e.g. call-id). No need to shout through the office in
this case! All that your media server needs to support is multiple calls on
the same orbit.

Christian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Procter
> Sent: Monday, May 10, 2004 10:39 AM
> To: [email-masked]
> Subject: [Sipping] Parking and retrieving calls
> 
> I have been working on a call park/retrieve implementation, based upon the
> example given in the Service Examples.  In particular, I want to solve the
> problem of identifying the parked call for retrieval by some mechanism
> other than the dialog id.
> 
> Has anyone else tried to solve this problem?  What do people think of this
> approach?  What changes can be made to make the approach better?
> 
> Regards,
> 
> Michael Procter
>