Subject: [MEDIACTRL] Basic IVR qusetions.

From: "Even, Roni" <[email-masked]>
Date: Sun, 17 Feb 2008 11:52:38 +0200

Hi,

I did another review and have some comments and questions on the draft that also have to do with the control framework.

1.	The terms Notifications, Reports and response are not clear, what is the relations when are they sent.
2.	When do you use dialogexit. For example in 6.3 you have dialog exit on the start and not on the prepare. Does it mean that you do not need to send a dialog exit on dialog prepare.
3.	What is the lifetime of dialog prepare, is it indefinite?
4.	In 6.5 in step 5 you have terminate, what is the meaning of this terminate since you do not see dialog exist report following it.
5.	The example using report or 202 like in 2 and 3. What is the difference in term of the protocol. I think it is tied to the issues of response and reports which are not clear

Roni

_______________________________________________
MEDIACTRL mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "McGlashan, Scott" <[email-masked]>
Date: Mon, 25 Feb 2008 12:01:32 +0000

Hi Roni,

thanks for the review comments. I waited until the latest version was published before replying, since I believe it addresses many of your comments. If not, let me know. See responses inline.

thanks

Scott

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Even, Roni
Sent: Sunday, February 17, 2008 10:53
To: [email-masked]
Subject: [MEDIACTRL] Basic IVR qusetions.

Hi,

[scott] I believe they are clearer in the -06 draft where the relationship between framework CONTROL/REPORT and Request/Response and Notification are clarified (Section 3.2). In particular we have changed how notification events are handled. Instead of using a REPORT associated with the dialogstart transaction, events are now sent in a CONTROL message with a new transactionid and the AS can respond with a 200 framework message. This means that notifications are no longer associated with the dialogstart transaction: notifications have their own transactions with the MS sending a CONTROL to notify the AS of an event (the MS is operating as a Framework Client in this case).

 1.  When do you use dialogexit. For example in 6.3 you have dialog exit on the start and not on the prepare. Does it mean that you do not need to send a dialog exit on dialog prepare.

[scott] a dialogexit notification is (now) always sent when an started dialog has exited. In a typical case, you would have

(a) dialogprepare in a CONTROL; MS prepares the dialog and responds with a <response> with 200/REPORT. The Framework transaction is complete. If the <response> has a success status, the dialog itself is an PREPARED state; otherwise the dialog is in a TERMINATED state.

(b) dialogstart  in a CONTROL: MS starts a dialog prepared in (a) and responds in 200/REPORT. The Framework transaction is  complete. If the response has a success status, the dialog itself is a STARTED state (otherwise the dialog is in a TERMINATED.
state and no notifcations are sent).

A dialogexit notification is sent by the MS when a dialog in STARTED state transitions to a TERMINATED state.

I've added a dialog lifecycle state machine  in Section 4.1 which should clarify.

 1.  What is the lifetime of dialog prepare, is it indefinite?

[scott] The dialogprepare request is carried in a CONTROL message to the MS: the request is complete when a (terminate) REPORT (or Framwork 200) with the same transactionid is sent with a <response> payload. The lifecycle of the dialog is different thought - it follows its own lifecycle (prepared->started->terminated).

 1.  In 6.5 in step 5 you have terminate, what is the meaning of this terminate since you do not see dialog exist report following it.

[scott] The status: terminate indicates that a Control Framework extended transaction is complete. In Section 6.5, a transaction is initiated with a dialogstart CONTROL message from the AS (1),  the transaction is extended with a 202 (2) and the transaction is complete when a REPORT with a status: terminate is sent from the MS (5). So at the stage the dialog has been successfully started.

 1.  The example using report or 202 like in 2 and 3. What is the difference in term of the protocol. I think it is tied to the issues of response and reports which are not clear

[scott] The framework offers the server 2 ways of responding to a CONTROL message: if the operation completes with the Transaction-Timeout, the server sends a 200 (or a error msg); if it cannot complete the operation before the timeout, the server extends the transaction by sending a 202, then zero or more Pending/Update REPORTs before sending a terminate REPORT - once that REPORT with a Status:terminate header is sent the transaction is complete.

Roni

---

From: [email-masked]
Date: Mon, 25 Feb 2008 13:46:18 +0100

Hi Scott,

I take advantage of this thread to report you some of my first  
comments on the new version of the drafts. They are just initial  
comments, since I didn't give them a detailed read yet. I don't have  
comments upon the conferencing and VoiceXML drafts, considering they  
don't have any new stuff yet.

Framework:
----------
1) SCFW has been chosen as unique token, but I guess it referred to  
the "SIP Control Framework" name... is it still fine, considering the  
framework has changed name now? Just an unimportant nit of course, a  
token is just a token...
2) I noticed you solved the 202+pending issue by not making the  
immediate 'pending' after the 202 mandatory. However, I fail to see a  
need for a 'pending' REPORT in the transactions at all, now...  
considering a transaction timeout can be refreshed through 'update'  
REPORTs, why sending a bodyless 'pending' first if a 202 is getting  
close to timeout? wouldn't a bodyless 'update' achieve the same result?
3) What should a Content-Type look like? does this imply that CONTROL  
or REPORT payloads might carry something different than XML? (small  
nit: the new header is missing both in Figure 10: Table 1 and section  
12.4).
4) The Changelog reports 'notify' status as added, but it doesn't  
appear anywhere... is it a typo and did you actually mean removed?
5) I see the new error code for already existing transactions (423).  
However, such error code would be carried in a response having the  
already existing transaction identifier in the header... couldn't this  
lead to undesired/undefined behaviour in the AS-MS interaction,  
possibly affecting the already existing transaction? Probably the case  
just needs a few more descriptive text to be ok.

IVR:
----
1) I have some doubts concerning the execution models: the logical  
execution models are the same as the explicit ones in the previous  
version, with the difference that now they are achieved through a  
combination of the three available children elements  
(prompt/collect/record):
1a) is the order of the subelements important? or does the  
contemporary presence of, let's say, <prompt> and <collect> always  
mean "prompt first and then collect"?
1b) why is <promptinfo> triggered only when a <prompt> is alone? an AS  
might be interested in receiving info on how a <prompt> ended even if  
it was part of a <collect> or <record>... of course this would mean  
attaching the <promptinfo> to the <collectinfo>/<recordinfo>...
1c) how do you iterate more times a <collect>/<record> request? in the  
old version of the draft, the 'iteration' attribute was shared between  
the template models, while now it only belongs to the <prompt>  
element... is a <collect> iterated 2 times only if it is preceded by a  
<prompt> with iterations=2? or can't it be iterated at all, and  
iterations are left to the AS logic? in both cases, some clarifying  
text is needed, IMHO.
2) The stream element is still a bit ambiguous (this applies for the  
conferencing package as well, but I'm focusing on its role in the IVR  
now):
2a) the direction is missing an 'inactive' value... wouldn't it be  
good to add it, considering it's an available value in SDP?
2b) when a <stream> is missing, the connectionid as a whole is used:  
in that case, I guess the media types (e.g. audio/video) is used to  
access the available streams; but what about when multiple streams of  
the same type are available for the same connection? e.g. a user who  
has two separate audio streams... I know it's not a typical use case,  
but I think the IVR draft should specify what happens if it comes  
(e.g. in a <record>, which stream is recorded, or if they are mixed  
and recorded together, or if an error is triggered, etc... same for  
DTMF collecting). The same applies for the conferencing package, in a  
<join> request for instance.
3) Finally, a comment upon the use of MS-generated CONTROL messages  
for events. I think that the AS should send no REPORT after such a  
notification, considering it is, exactly, just a notification, and no  
additional elaborations from the AS are needed (at least, no  
elaboration the MS should be directly concerned of). My suggestion  
would be to have a mandatory 200 in response to these CONTROL  
messages: this would solve the issue you noticed about incoming  
REPORTS from the AS.

Hope this helped, regards,
Lorenzo

Quoting "McGlashan, Scott" <[email-masked]>:

> Hi Roni,
>
> thanks for the review comments. I waited until the latest version   
> was published before replying, since I believe it addresses many of   
> your comments. If not, let me know. See responses inline.
>
> thanks
>
> Scott
>
> I did another review and have some comments and questions on the   
> draft that also have to do with the control framework.
>
>
>  1.  The terms Notifications, Reports and response are not clear,   
> what is the relations when are they sent.
>
> [scott] I believe they are clearer in the -06 draft where the   
> relationship between framework CONTROL/REPORT and Request/Response   
> and Notification are clarified (Section 3.2). In particular we have   
> changed how notification events are handled. Instead of using a   
> REPORT associated with the dialogstart transaction, events are now   
> sent in a CONTROL message with a new transactionid and the AS can   
> respond with a 200 framework message. This means that notifications   
> are no longer associated with the dialogstart transaction:   
> notifications have their own transactions with the MS sending a   
> CONTROL to notify the AS of an event (the MS is operating as a   
> Framework Client in this case).
>
>
>  1.  When do you use dialogexit. For example in 6.3 you have dialog   
> exit on the start and not on the prepare. Does it mean that you do   
> not need to send a dialog exit on dialog prepare.
>
>
> [scott] a dialogexit notification is (now) always sent when an   
> started dialog has exited. In a typical case, you would have
>
> (a) dialogprepare in a CONTROL; MS prepares the dialog and responds   
> with a <response> with 200/REPORT. The Framework transaction is   
> complete. If the <response> has a success status, the dialog itself   
> is an PREPARED state; otherwise the dialog is in a TERMINATED state.
>
> (b) dialogstart  in a CONTROL: MS starts a dialog prepared in (a)   
> and responds in 200/REPORT. The Framework transaction is  complete.   
> If the response has a success status, the dialog itself is a STARTED  
>  state (otherwise the dialog is in a TERMINATED.
> [scott] The dialogprepare request is carried in a CONTROL message to  
>  the MS: the request is complete when a (terminate) REPORT (or   
> Framwork 200) with the same transactionid is sent with a <response>   
> payload. The lifecycle of the dialog is different thought - it   
> follows its own lifecycle (prepared->started->terminated).
>
>
>  1.  In 6.5 in step 5 you have terminate, what is the meaning of   
> this terminate since you do not see dialog exist report following it.
>
>
> [scott] The status: terminate indicates that a Control Framework   
> extended transaction is complete. In Section 6.5, a transaction is   
> initiated with a dialogstart CONTROL message from the AS (1),  the   
> transaction is extended with a 202 (2) and the transaction is   
> complete when a REPORT with a status: terminate is sent from the MS   
> (5). So at the stage the dialog has been successfully started.
>
>
>
>  1.  The example using report or 202 like in 2 and 3. What is the   
> difference in term of the protocol. I think it is tied to the issues  
>  of response and reports which are not clear
>
>
> [scott] The framework offers the server 2 ways of responding to a   
> CONTROL message: if the operation completes with the   
> Transaction-Timeout, the server sends a 200 (or a error msg); if it   
> cannot complete the operation before the timeout, the server extends  
>  the transaction by sending a 202, then zero or more Pending/Update   
> REPORTs before sending a terminate REPORT - once that REPORT with a   
> Status:terminate header is sent the transaction is complete.
>
>
>
> Roni
>

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]
_______________________________________________
MEDIACTRL mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 26 Feb 2008 09:29:11 +0200

Scott,

Thanks, I will look at the updated draft.

Two more question on the dialog prepare

"What is the lifetime of dialog prepare, is it indefinite? 

[scott] The dialogprepare request is carried in a CONTROL message to the
MS: the request is complete when a (terminate) REPORT (or Framwork 200)
with the same transactionid is sent with a <response> payload. The
lifecycle of the dialog is different thought - it follows its own
lifecycle (prepared->started->terminated). "

1.	Does this mean that I can send a dialog prepare and one month
later do a dialog start.
2.	What is the life time of the prepared dialog, If I do
prepare->start->terminated can I re-use the prepared dialog.

Thanks

Roni

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 26 Feb 2008 10:22:52 -0000

Framework:
----------

[Chris Boulton] Yes - you are correct.  We should probably change this
to something like MCFW (Media Control Framework)?

[Chris Boulton] Yes it would.  If the rest of the group are happy then I
will remove the 'pending' state and re-craft the text.  Please shout now
if you spot any problems.

[Chris Boulton] It does imply they could be different from XML - and
should be constrained by the individual control packages.

[Chris Boulton] Yes - I did 'add' it and then we 'fixed' your other
issue for dialog state which resulted in it disappearing.  Just ignore.

[Chris Boulton] ah - good catch.  Any ideas on this one?

---

From: "McGlashan, Scott" <[email-masked]>
Date: Tue, 26 Feb 2008 10:34:11 +0000

Hi Roni,

 1.  Does this mean that I can send a dialog prepare and one month later do a dialog start.

[scott] As currently drafted, yes since the spec doesn't defined a maximum time that a dialog can remain in the prepared state (cf. conference when it is created - how long should it remain created without being used?). If you think this is a problem, we can add a statement that the duration of the prepared state is limited and then either state a (recommended?) maximum time, or let the MS determine the timeout.  Probably the stating a timeout on the spec would be cleanest and consistent between implementations.

 1.  What is the life time of the prepared dialog, If I do prepare->start->terminated can I re-use the prepared dialog.

[scott] No, since the dialog is in a terminated state, the dialogid is not longer valid - so you can't re-start it. You would have to prepare/start another dialog with a new dialogid. By analogy with conferencing, this is similar to a conference being created, used and then destroyed - would we expect to reused a terminated conference?

Let me know if you think we need changes on these issues.

thanks

Scott

________________________________
From: Even, Roni [mailto:[email-masked]]
Sent: Tuesday, February 26, 2008 08:29
To: McGlashan, Scott; [email-masked]
Subject: RE: Basic IVR qusetions.

Scott,

[scott] The dialogprepare request is carried in a CONTROL message to the MS: the request is complete when a (terminate) REPORT (or Framwork 200) with the same transactionid is sent with a <response> payload. The lifecycle of the dialog is different thought - it follows its own lifecycle (prepared->started->terminated). "

 1.  Does this mean that I can send a dialog prepare and one month later do a dialog start.
 2.  What is the life time of the prepared dialog, If I do prepare->start->terminated can I re-use the prepared dialog.

Thanks
Roni

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 26 Feb 2008 12:38:46 +0200

Scott,

In conferencing you have recurrences. The conference ID can remain for
ever. 

This serves like a template.

Roni

From: McGlashan, Scott [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2008 12:34 PM
To: Even, Roni; [email-masked]
Subject: RE: Basic IVR qusetions.

Hi Roni,

[scott] As currently drafted, yes since the spec doesn't defined a
maximum time that a dialog can remain in the prepared state (cf.
conference when it is created - how long should it remain created
without being used?). If you think this is a problem, we can add a
statement that the duration of the prepared state is limited and then
either state a (recommended?) maximum time, or let the MS determine the
timeout.  Probably the stating a timeout on the spec would be cleanest
and consistent between implementations. 

1.	What is the life time of the prepared dialog, If I do
prepare->start->terminated can I re-use the prepared dialog. 

[scott] No, since the dialog is in a terminated state, the dialogid is
not longer valid - so you can't re-start it. You would have to
prepare/start another dialog with a new dialogid. By analogy with
conferencing, this is similar to a conference being created, used and
then destroyed - would we expect to reused a terminated conference? 

thanks

Scott

Scott,

 

 

Thanks

Roni

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 26 Feb 2008 12:23:10 -0000

Scott,

Roni

[Chris Boulton] Yes - and from an AS point of view it is modeled that
way.  From an MS point of view it would either a) result in the mapping
of the long-lived ID to the next occurrence of recurring instance OR b)
the conference package allows for one to be specified on creation.

Chris.

---

From: "McGlashan, Scott" <[email-masked]>
Date: Tue, 26 Feb 2008 12:32:21 +0000

Hi Lorenzo,

Great comments.

IVR:
----
1) I have some doubts concerning the execution models: the logical execution models are the same as the explicit ones in the previous version, with the difference that now they are achieved through a combination of the three available children elements
(prompt/collect/record):
1a) is the order of the subelements important? or does the contemporary presence of, let's say, <prompt> and <collect> always mean "prompt first and then collect"?

[scott] In the current model (and schema) of <basicivr>, the order is not important. The execution just depends on the presence or absence of the child elements. We could make the order important, requiring <prompt> to occur before <collect> and <record>. Enforcing this sequence would make the schema simpler, but would require developers to follow this order - is this a good thing or bad for developers? i.e.

<basicivr>
 <collect ...>
 <prompt>
</basicivr>

would be illegal in a sequenced model. However, if we want a sequenced model, it can be easily changed. Let me know if someone wants the sequence model, otherwise I'll just clarify in the spec that element order is not significant.

1b) why is <promptinfo> triggered only when a <prompt> is alone? an AS might be interested in receiving info on how a <prompt> ended even if it was part of a <collect> or <record>... of course this would mean attaching the <promptinfo> to the <collectinfo>/<recordinfo>...

[scott] Section 5 currently states "If the dialog terminated normally (i.e. not due to an error or to a <dialogterminate> request), then the MS MUST report the results for at least the core operation: .." where the intention was that MS MAY also report information about other elements - i.e. if it is a prompt and collect, then the MS may also report on the <prompt> but must report on the <collect>.

If you think this is too weak - i.e. AS would always want a report on all executed elements - then we could strengthen this so that the MS MUST report on all elements present. So if there is a <prompt> and <record>, both elements would be reported on. Let me know if this option is better and I'll update the draft.

1c) how do you iterate more times a <collect>/<record> request? in the old version of the draft, the 'iteration' attribute was shared between the template models, while now it only belongs to the <prompt> element... is a <collect> iterated 2 times only if it is preceded by a <prompt> with iterations=2? or can't it be iterated at all, and iterations are left to the AS logic? in both cases, some clarifying text is needed, IMHO.

[scott] Yes you are correct - previous versions allowed the promptandcollect and promptandrecord dialogs to be iterated. In the current spec, no dialog iterations are permitted - only iterations of the <prompt> content - so it would be left to the AS logic to re-start dialogs, etc. I'll update the spec to restore the previous functionality by adding iterations/duration attributes to <basicivr> so that the whole dialog container can be repeated until a successful collect/record (reporting only the last result).

If we have duration/iterations on the <basicivr>, then do we still need these attributes on <prompt> as well? If we remove them, then this would rule out

<basicivr iterations="5">
 <prompt iterations=3">
  ...
 </prompt>
 <collect/>
</basicivr>

i.e. a maximum of 5 promptandcollect attempts. For each attempt, the prompt content would be iterated 3 times. Removing iterations from prompt would make the model simpler, but would rule out usage where the prompts can be repeated independently of the dialog repetition - are there any use cases for this? My preference would be to only have the iterations/duration on the <basicivr> dialog (makes the playannouncment use case simpler since this is just one iterations attribute specified).

2) The stream element is still a bit ambiguous (this applies for the conferencing package as well, but I'm focusing on its role in the IVR
now):
2a) the direction is missing an 'inactive' value... wouldn't it be good to add it, considering it's an available value in SDP?

[scott] Do you intend 'inactive' to indicate explicitly that a specific media stream is not to be used? This seems like a good idea.

2b) when a <stream> is missing, the connectionid as a whole is used:
in that case, I guess the media types (e.g. audio/video) is used to access the available streams; but what about when multiple streams of the same type are available for the same connection? e.g. a user who has two separate audio streams... I know it's not a typical use case, but I think the IVR draft should specify what happens if it comes (e.g. in a <record>, which stream is recorded, or if they are mixed and recorded together, or if an error is triggered, etc... same for DTMF collecting). The same applies for the conferencing package, in a <join> request for instance.

[scott] Good points.

[1] So one use case would be there are 2 output audio streams from a connection, no <stream> elements are used to control them, and a <record/> is ordered. I think the behavior will largely depend on the recording format - does it allow multiple streams to be recorded? Most don't, but some container formats (e.g. mp4, avi) do allow it.  Some options:

(a) If a format is specified which support multiple streams, and the MS supports this format, then the streams are recorded in this format. If a recording format is specified which doesn't support multiple streams, and the MS supports mixing the streams into a single track format, then it may record them in this way; if it doesn't support mixing then it must raise an error.

(b)  If a format is specified which support multiple streams, and the MS supports this format, then the streams are recorded in this format. If a recording format is specified which doesn't support multiple streams, then the MS must raise an error.

(c) behavior is undefined.

My preference is for (b) to keep things simple and not get into how an MS selects/mixes streams in the IVR context. Are there other options we should look at? Does anyone have a preference amongst these options?

[2] Same use case with multiple audio stream and <collect/> - assume DTMF could be transmitted in both or just one. Some options:

(a) We could require the MS to monitor both for DTMF and add them to its digit buffer. Difficulty here could be timing - two DTMFs arrive at the same time, but they would need to put them into the buffer in some order. Pretty exotic edge case though.

(b) We could allow monitoring of both, but if the MS doesn't support this then it must raise an error.

(c) it is always an error.

(d) behavior is undefined.

My (weak) preference here would be for (b). Anyone else have a preference here?

[3] Since you raise this issue with connection output streams, we also have a similar issue with connection input stream and <prompt>: what happens when MS attempts to play a media container format with multiple tracks of the same type and there is only 1 connection stream of that type? Options:

(a) If the MS supports mixing of the media into a single stream, then it may do so. If the MS doesn't support this, it must raise an error.

(b) It must raise an error.

(c) behavior is undefined.

My preference is for (b) to avoid getting into how MS select/mix tracks.

[4] As [3] but with multiple connection input streams: e.g. 2 audio tracks in the container format and 2 audio streams on the connection. The issue here is which track is mapped to which connection stream. My preference would be to indicate that mapping tracks and stream is not defined in this spec.

3) Finally, a comment upon the use of MS-generated CONTROL messages for events. I think that the AS should send no REPORT after such a notification, considering it is, exactly, just a notification, and no additional elaborations from the AS are needed (at least, no elaboration the MS should be directly concerned of). My suggestion would be to have a mandatory 200 in response to these CONTROL
messages: this would solve the issue you noticed about incoming REPORTS from the AS.

[scott] Agreed. I'll update the spec with this.

Quoting "McGlashan, Scott" <[email-masked]>:

> Hi Roni,
>
> thanks for the review comments. I waited until the latest version was
> published before replying, since I believe it addresses many of your
> comments. If not, let me know. See responses inline.
>
> thanks
>
> Scott
>
> I did another review and have some comments and questions on the draft
> that also have to do with the control framework.
>
>
> relationship between framework CONTROL/REPORT and Request/Response and
> Notification are clarified (Section 3.2). In particular we have
> changed how notification events are handled. Instead of using a REPORT
> associated with the dialogstart transaction, events are now sent in a
> CONTROL message with a new transactionid and the AS can respond with a
> 200 framework message. This means that notifications are no longer
> associated with the dialogstart transaction:
> exit on the start and not on the prepare. Does it mean that you do not
> need to send a dialog exit on dialog prepare.
>
>
> [scott] a dialogexit notification is (now) always sent when an started
> dialog has exited. In a typical case, you would have
>
> complete. If the <response> has a success status, the dialog itself is
> an PREPARED state; otherwise the dialog is in a TERMINATED state.
>
> (b) dialogstart  in a CONTROL: MS starts a dialog prepared in (a) and
> responds in 200/REPORT. The Framework transaction is  complete.
> the MS: the request is complete when a (terminate) REPORT (or Framwork
> 200) with the same transactionid is sent with a <response> payload.
> The lifecycle of the dialog is different thought - it follows its own
> lifecycle (prepared->started->terminated).
>
>
>  1.  In 6.5 in step 5 you have terminate, what is the meaning of this
> terminate since you do not see dialog exist report following it.
>
>
> transaction is extended with a 202 (2) and the transaction is complete
> when a REPORT with a status: terminate is sent from the MS (5). So at
> the stage the dialog has been successfully started.
>
>
>

Dipartimento di Informatica e Sistemistica Università degli Studi di Napoli "Federico II"

---

From: "McGlashan, Scott" <[email-masked]>
Date: Tue, 26 Feb 2008 13:07:18 +0000

I'm trying to reconcile the concept of recurrences/templates with what we currently have in the conference package.

We can create a conference :

<createconference conferenceid="conf1"/>

So we now have a unique conference instance with id conf1. As you say, this instance could remain forever, but if we destroy it with

<destroyconference conferenceid="conf1"/>

then the conference instance is terminated - its lifecycle is complete (associated resources released, etc). I think this is Chris's b) option. So I interpret conference recurrence/templates are AS concepts but the AS can make these concepts correspond to one or more conference instances on the MS.

This also raises the issue of whether conference ids are globally unique to all conferences created on an MS - or just unique with respect to the active conferences on the MS. If the latter, then a conferenceid could be re-cycled: i.e. once conf1 is destroyed, it could used in another <createconference> command. The same issue needs clarification with dialogid in the IVR package.

Scott

________________________________
From: Chris Boulton [mailto:[email-masked]]
Sent: Tuesday, February 26, 2008 13:23
To: Even, Roni; McGlashan, Scott; [email-masked]
Subject: RE: [MEDIACTRL] Basic IVR qusetions.

Scott,
In conferencing you have recurrences. The conference ID can remain for ever.
This serves like a template.
Roni

[Chris Boulton] Yes - and from an AS point of view it is modeled that way.  From an MS point of view it would either a) result in the mapping of the long-lived ID to the next occurrence of recurring instance OR b) the conference package allows for one to be specified on creation.

Chris.

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 26 Feb 2008 15:14:43 +0200

Scott,

I do not have a favorable way, the AS can create a dialog/conference and
use it many times or it can create it each time.

If we chose to re-use that means that for IVR prepare we can keep the
dialog for later use and add dialog delete command. Same for conference.

BTW: about the timeout for the dialog itself (prepare dialog and much
late do dialog start) it is part of the same topic. Maybe we need dialog
delete anyhow.

Roni

From: McGlashan, Scott [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2008 3:07 PM
To: Chris Boulton; Even, Roni; [email-masked]
Subject: RE: [MEDIACTRL] Basic IVR qusetions.

I'm trying to reconcile the concept of recurrences/templates with what
we currently have in the conference package.

So we now have a unique conference instance with id conf1. As you say,
this instance could remain forever, but if we destroy it with 

then the conference instance is terminated - its lifecycle is complete
(associated resources released, etc). I think this is Chris's b) option.
So I interpret conference recurrence/templates are AS concepts but the
AS can make these concepts correspond to one or more conference
instances on the MS. 

This also raises the issue of whether conference ids are globally unique
to all conferences created on an MS - or just unique with respect to the
active conferences on the MS. If the latter, then a conferenceid could
be re-cycled: i.e. once conf1 is destroyed, it could used in another
<createconference> command. The same issue needs clarification with
dialogid in the IVR package. 

Scott

Scott,

Roni

Chris.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 26 Feb 2008 11:03:37 -0600

Hi, Roni,

Are you raising a garbage collection issue here ("when can I discard the prepared dialog?"), or an issue about detecting that a restart has taken place ("I'm holding a dialog for someone who doesn't remember that I have it"), or another issue?

Just so I understand.

Thanks,

Spencer
  ----- Original Message ----- 
  From: McGlashan, Scott 
  To: Even, Roni ; [email-masked] 
  Sent: Tuesday, February 26, 2008 4:34 AM
  Subject: Re: [MEDIACTRL] Basic IVR qusetions.

  Hi Roni,

    1.. Does this mean that I can send a dialog prepare and one month later do a dialog start.

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 27 Feb 2008 08:41:29 +0200

Spencer,

The issue I am raising has to do with the life span of a prepared dialog (I think this is what you call garbage collection. One way is for an AS to prepare all potential dialogs when it connects to the MS and use them later. This makes sense if you can re-use dialogs. We have to remember that in some applications there are dialogs that repeated all the time. For example ("welcome to the conference bridge, please enter your pin code number").

The other scenario of AS restart should also be addressed, this is a good point and should be solved even if prepared dialogs are not re-used, this means that if we have a timeout on a prepared dialog this issue is also resolved.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Tuesday, February 26, 2008 7:04 PM
To: [email-masked]
Subject: Re: [MEDIACTRL] Basic IVR qusetions.

Hi, Roni,

Just so I understand.

Thanks,

Spencer

	----- Original Message ----- 

	From: McGlashan, Scott <mailto:[email-masked]>  

	To: Even, Roni <mailto:[email-masked]>  ; [email-masked] 

	Hi Roni,

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 27 Feb 2008 09:25:23 -0600

Hi, Roni,

OK, this is just distributed state management - we know how to do that, we just need to remember that we need to manage distributed state for prepared dialogs!

Thanks,

Spencer
  ----- Original Message ----- 
  From: Even, Roni 
  To: Spencer Dawkins ; [email-masked] 
  Sent: Wednesday, February 27, 2008 12:41 AM
  Subject: RE: [MEDIACTRL] Basic IVR qusetions.

  Spencer,

  Roni

------------------------------------------------------------------------------

  Hi, Roni,

  Just so I understand.

  Thanks,

  Spencer

    ----- Original Message ----- 

    From: McGlashan, Scott 

    Hi Roni,