Subject: [Sip] Dialog-State Use Cases

From: "Christian Stredicke" <[email-masked]>
Date: Thu, 13 Nov 2003 19:04:45 -0600

Hi Rohan,

looks like we have just been bombed back into the requirements phase of
the dialog (or whatever the name is) package. 

I see the following use-cases:

1. STATUS information

We need to see if a dialog is "ringing", "talking", "on hold", or has
just been "terminated". Also it would be nice to have the to- and from,
maybe referred-by and the start of the "talking" (so that we can
calculate the duration). This information is nice for LED and
SWITCHBOARD applications. 

2. Call pickup, join, and other ACTIONS

The dialog state subscriber needs to know what URL to dial in order to
pick up a call or on how to join a call. Other actions might also be
indicated.

3. The question of HANDSET-LIFTING

We need to know if handsets have been lifted up (that's a simple
requirement from the switchboard people which laugh at us if we say
"impossible"; it is also needed for AUTOMATIC CALL BACK). We could model
this as dialog where "to" is not set yet.

That's all on my wish list! No need for CSeq or other stuff end-users
are not interested in!

Please don't forget SIP did not replace the good old PBX yet and there
is a reason for this.

CS

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Nov 2003 20:25:54 -0500

I think a lot of confusion could be eliminated by renaming the document 
and the event package it defines. While it has something to do with 
dialogs, it isn't fundamentally about dialogs. For instance, it has 
*nothing* to do with dialogs containing only subscriptions.

It is largely but not entirely related to dialogs that contain an 
invitation. But it is concerned with some things that can't be learned 
from just that.

I suggest something like "call-info".

More inline...

	Paul

> this as dialog where "to" is not set yet.

It really need have nothing to do with lifting a handset. Lots of 
devices don't even have a handset - at least not one you lift.

I think it is about being in a state of preparing to make a call. But it 
is more than that, because not all devices would want to report this 
when preparing to make a call. It also has something to do with being 
unwilling or unable to receive a call while in this state, and/or 
wanting to seize a shared line resource.

---

From: "Christian Stredicke" <[email-masked]>
Date: Fri, 14 Nov 2003 00:35:07 -0600

> I suggest something like "call-info".
Absolutely!

> wanting to seize a shared line resource.

Call it "virtual handset lifting"... I think we are in agreement that we
need something to indicate inability to receive a call while in this
state.

Christian

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 14 Nov 2003 16:03:39 -0600

Christian,

Thanks for your quick turn around.

-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 14 Nov 2003 16:07:08 -0600

On Thursday, November 13, 2003, at 07:25 PM, Paul Kyzivat wrote:

> I think a lot of confusion could be eliminated by renaming the 
> document and the event package it defines. While it has something to 
> do with dialogs, it isn't fundamentally about dialogs. For instance, 
> it has *nothing* to do with dialogs containing only subscriptions.
>

That was the original title, but for some reason we changed that.

Event package for SIP session and session-participation information ?

thanks,
-rohan

> I think it is about being in a state of preparing to make a call. But 
> it is more than that, because not all devices would want to report 
> this when preparing to make a call. It also has something to do with 
> being unwilling or unable to receive a call while in this state, 
> and/or wanting to seize a shared line resource.