Subject: [splices] SIP INVOKE Method - The Model

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Thu, 21 Jul 2011 07:53:27 -0400

Hi,

The following is the model definition for the SIP INVOKE method:

The SIP INVOKE method is modeled as a Call Control method that allows one UA to manipulate the state of an INVITE-based dialog on a remote UA.

The following diagram captures the INVITE-based dialog FSM and how the INVOKE actions fit into that FSM. The left part of the diagram covers the UAC actions, while the right part covers the UAS actions.
The actions that applicable to both are in the middle. e.g. Hold/Unhold.

                        UAC Actions    :    UAS Actions
                        -----------    :    -----------
                                       :
                                       :
                                       :
                                 +-----------+
                                 |           |
                                 |   IDLE    |
                                 |           |
                                 +-----------+
                                       |
                            INVITE/1xx |
                            (Initiate) |
                                       |
                                       |
                                       V
                                 +-----------+
                                 |           |
                       +---------|   EARLY   |---------+
                       |         |           |         |
           CANCEL      |         +-----------+         | 302
           (Terminate) |               |               | (Send to VM)
                       |               | OK/ACK        |
                       |               | (Answer)      | 603 [441?]
                       |               |               | (Decline)
                       |               |               |
                       |               V               |
                       |         +-----------+         |
                       |         |           |         |
                       |         |  ACTIVE   |         |
                       |         |           |         |
                       |         +-----------+         |
                       |           ^   |   |           |
                       |           |   |   |           |
                       |          Re-INVITE/OK         |
                       |          (Hold/Unhold)        |
                       |           |   |   |           |
                       |           +---|---+           |
                       |               |               |
                       |               |               |
                       |             BYE/OK            |
                       |          (Terminate)          |
                       |               |               |
                       |               |               |
                       |               V               |
                       |         +-----------+         |
                       |         |           |         |
                       +-------->|TERMINATED |<--------+
                                 |           |
                                 +-----------+
                                       :
                                       :
                                       :
                                       :
                                       :

We would appreciate any comments.

Thanks,
Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jul 2011 10:19:09 -0400

Its not evident to me that this model includes device control such as 
selecting handset/headset/speakerphone, control of lights/buttons, etc.. 
Yet that seems to be an important part of what we want this for.

The difference is that what you have included is what fits within the 
existing state model for dialogs, while that other stuff requires a more 
extensive model of the device.

So, if we want this mechanism to be able to select media sources and 
sinks on the device, then the model needs to encompass media sources and 
sinks on the device. If we want to control or be conditional on 
lights/buttons then lights and buttons need to be part of the model, ...

     Thanks,
     Paul

On 7/21/11 7:53 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> The SIP INVOKE method is modeled as a *Call Control* method that 
> allows one UA to manipulate the state of an *INVITE-based dialog *on a 
> remote UA.
>
> The following diagram captures the INVITE-based dialog FSM and how the 
> INVOKE actions fit into that FSM. The left part of the diagram covers 
> the UAC actions, while the right part covers the UAS actions.
>
> UAC Actions:UAS Actions
> -----------:-----------
> ||
> |IDLE|
> ||
> ||
> +---------|EARLY|---------+
>
> ||||
>
> CANCEL|+-----------+| 302
>
> (Terminate) ||| (Send to VM)
>
> || OK/ACK|
>
> || (Answer)| 603 [441?]
>
> ||| (Decline)
>
> |||
>
> |V|
>
> |+-----------+|
>
> ||||
>
> ||ACTIVE||
>
> ||||
>
> |+-----------+|
>
> |^|||
>
> |||||
>
> |Re-INVITE/OK|
>
> |(Hold/Unhold)|
>
> |||||
>
> |+---|---+|
>
> |||
>
> |||
>
> |BYE/OK|
>
> |(Terminate)|
>
> |||
>
> |||
>
> |V|
>
> |+-----------+|
>
> ||||
>
> ||
> _______________________________________________
> splices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/splices

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 25 Jul 2011 16:01:06 -0400

What do people who work with "call centers" and other CTI applications say they need as a command set?

Dale