Subject: [MEDIACTRL] Fwd: I-D ACTION:draft-boulton-conference-control-package-02.txt

From: "Tim Melanchuk" <[email-masked]>
Date: Tue, 6 Mar 2007 15:57:28 -0800

The following are the major changes between the -02 of the draft and
the -01 version.

o  clarified the model for join operations and introduced several new
   package error codes

o  added definition for MS connection

cheers.
timm

---------- Forwarded message ----------
From: [email-masked] <[email-masked]>
Date: Mar 6, 2007 12:50 PM
Subject: I-D ACTION:draft-boulton-conference-control-package-02.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : A Conference Control Package for the Session
Initiation Protocol (SIP)
        Author(s)       : C. Boulton, et al.
        Filename        : draft-boulton-conference-control-package-02.txt
        Pages           : 37
        Date            : 2007-3-6

This document defines a Session Initiation (SIP) Control Package for
   Conference Control.  The control of Media Servers and their related
   resources in decomposed network architectures plays an important role
   in various Next Generation Networks.  This Control Package aims to
   fulfill Conferencing requirements using the SIP Control Framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-boulton-conference-control-package-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-
boulton-conference-control-package-02.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: <[email-masked]>
Date: Wed, 14 Mar 2007 12:52:27 -0400

Hi Tim M., Scott M., Chris B. and folks, 

Regarding the updated conference control package and IVR control package
drafts - 

Consider a conferencing service use case that includes (among other
things) routine stuff like: 

a. Prompt & collect a caller/participant for conference access code
  b. Prompt & record participant's name
  c. Music to all legs until host joins

d. Play recorded participant names to the conference as legs are
admitted

e. Play 'person XX has left the conference' to the conference as a leg
leaves

 and
  f. Host participant can hit a DTMF string to mute/un-mute all legs
except his/her own
  g. Any participant can hit a DTMF string to mute/unmute his/her own
leg

I'm trying to understand how the conference & IVR control packages
'dance' together to support the overall service. What I conclude from
reading the drafts is that the two packages may run concurrently on the
same call legs/conference, and it is the role of the IVR control package
to deal with *all* aspects of announcements/recordings/music and
listening for prompts, including those that are for the conference as a
whole (e.g. c, d, e above).  Is that correct? And so, for example, the
IVR control package can issue a request to play an announcement or
recording to the conference.

Then, a few particulars

- In the IVR control package draft end of Section 4.1.2 that talks about
a promptandrecord dialog for a conference: does the prompt part really
mean prompt-the-conference, so any (all) unmated participant(s) could be
the respondent(s)?

- How is (f) above accomplished? 
- How is (g) above accomplished?

And, separate question - any thoughts or plans about adding sidebar
capabilities into the conference control package? 

Thanks.

cheers,

Gary

________________________________

From: Tim Melanchuk [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 6:57 PM
To: [email-masked]
Subject: [MEDIACTRL] Fwd:
I-DACTION:draft-boulton-conference-control-package-02.txt

cheers.
timm

---------- Forwarded message ----------
From: [email-masked] < [email-masked]
<mailto:[email-masked]> >
Date: Mar 6, 2007 12:50 PM
Subject: I-D ACTION:draft-boulton-conference-control-package-02.txt
To: [email-masked]

        Title           : A Conference Control Package for the Session
Initiation Protocol (SIP)
        Author(s)       : C. Boulton, et al.
        Filename        :
draft-boulton-conference-control-package-02.txt 
        Pages           : 37
        Date            : 2007-3-6

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-boulton-conference-control-pac
kage-02.txt 

Send a message to:
        [email-masked].
In the body type:
        "FILE
/internet-drafts/draft-boulton-conference-control-package-02.txt".

        a MIME-compliant mail reader.  Different MIME-compliant mail
readers

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 14 Mar 2007 19:04:56 +0200

Gary,

The dancing is choreographed by the AS. 

a and b are using the IVR.  There is no conference.

 After b (step c) the user is moved by the AS to the created conference
using the conference package. Playing music and even a video slide is
done using some announcements means. 

Announcements like who joined and who left are the same as step c. the
difference that in c the users are on hold. (not sending just receiving)

 F and g require that DTMF will be processed by MS and sent to AS to
decide what to do. This can be based on application interaction and kpml
(RFC 4730)

Roni Even

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 6:52 PM
To: [email-masked]; [email-masked]
Subject: RE: [MEDIACTRL]
Fwd:I-DACTION:draft-boulton-conference-control-package-02.txt

 and

Then, a few particulars

Thanks.

cheers,

Gary

cheers.
timm

---------- Forwarded message ----------

Send a message to:
        [email-masked].
In the body type:
        "FILE

---

From: <[email-masked]>
Date: Wed, 14 Mar 2007 13:26:47 -0400

Hi Roni,

I get the part about the AS choreographing (although depending on how
robust the AS design is, the MS may also have to choreograph), and I
could rationalize all of the items, but was looking for more detail on
(f) and (g).

For example, if I want monitor all call legs for the same DMTF, do I
have to send a request for every call leg? 

If I want to mute all legs except the host, do I have to send individual
requests for those individual call legs? Is that as good as it gets?

Is there any thinking about including a monitoring request in the IVR
control package as opposed to doing a separate Subscribe/Notify session?

Gary

From: Even, Roni [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 1:05 PM
To: MUNSON, GARY A (GARY A); [email-masked]; [email-masked]
Subject: RE: [MEDIACTRL]
Fwd:I-DACTION:draft-boulton-conference-control-package-02.txt

Gary,

Roni Even

 and

Then, a few particulars

Thanks.

cheers,

Gary

cheers.
timm

---------- Forwarded message ----------

Send a message to:
        [email-masked].
In the body type:
        "FILE

---

From: "McGlashan, Scott" <[email-masked]>
Date: Wed, 14 Mar 2007 19:16:49 +0100

Hi Gary,
 
Below is the rough message flow between AS and MS needed for the use
cases based in the current package versions. Based on these versions,
the answers to your questions are:
 
If I want monitor all call legs for the same DMTF, do I have to send a
request for every call leg? [yes]

If I want to mute all legs except the host, do I have to send individual
requests for those individual call legs? [yes]   Is that as good as it
gets? [see below]

Is there any thinking about including a monitoring request in the IVR
control package as opposed to doing a separate Subscribe/Notify session?
[not sure what you mean by 'monitoring request']

We have been thinking about a 'group' concept (a set of participants) to
which IVR and conference operations could be applied, but it isn't yet
in the drafts. This would reduce the message flow between AS and MS for
operations like 'mute all participants except 1' and 'activate a dtmf
dialog listening for digits on all call legs except particpant x'. We
wanted to make sure that the 'group' approach has clean semantics and
address edge cases (e.g. the operation has been applied to some
participants, but it fails with one ...) before adding it. 
 
And your other questions
 
 In the IVR control package draft end of Section 4.1.2 that talks about
a promptandrecord dialog for a conference: does the prompt part really
mean prompt-the-conference, so any (all) unmated participant(s) could be
the respondent(s)?
 
[Yes. The prompt would be played to the whole conference. Any
participant who isn't muted is recorded. Frequently, promptandrecord to
a conference is done without a prompt - i.e. record whatever anyone says
on the conference, but the prompt could be used to let people know they
are being recorded ...] 

[Yes, definitely. If you have a use case interaction flow which the
specs should address, please send it. We need more use case
descriptions!]  

thanks
 
Scott

---- details -----

Assume connection-id "p1" and "host" are a known pariticpant connections
to join
conference and that conference-id "conf1" is the conference.
 
I'll skip the detailed interaction (especially responses) and focus on
messages relevant to the use cases.

AS -> MS: AS requests playing of prompt and dtmf collection using IVR
          package 
 
<dialogstart src="basicivr:promptandcollect" connection-id="con1">
<data>
   <item name="prompts" value="http://www.example.com/accessCode.wav"/>
   <item name="maxdigits" value="4"/>
 </data>
</dialogstart>

MS -> AS: MS returns notification event with dtmf collected payload
 
<event name="dialogexit">
    <data>
       <item name="status" value="1"/>
       <item name="result" value="1234"/>
    </data>
</event>

 
AS -> MS: AS requests recording participant name using IVR package 
 
<dialogstart src="basicivr:promptandrecord" connection-id="p1">
    <data>
       <item name="prompts"
value="http://www.example.com/sayname.wav"/>
       <item name="dtmfterm" value="false"/>
       <item name="maxtime" value="30s"/>
    </data>
</dialogstart>

MS -> AS: MS returns notification event with URI of recording 
 
<event name="dialogexit" dialogid="vxi83">
 <data>
  <item name="status" value="1"/>
  <item name="result" value="http://www.example.com/recording1.wav"/>
 </data>
</event>

 
First we need to create a conference
 
AS -> MS: AS requests conference creation 
 
<createconference conf-id="conf1"/>
 
then AS can play music to conference using IVR package
 
AS -> MS: AS requests prompt (repeatedly) played to conference
 
<dialogstart src="basicivr:playannouncement" conf-id="conf1">
    <data>
       <item name="prompts"  value="http://www.example.com/music.wav"/>
       <item name="iterations" value="0"/>
    </data>
</dialogstart>

and the AS can stop this dialog at any time using <dialogterminate/> in
the IVR package. 

 
first join participant to conference 
 
AS -> MS: AS requests p1 is joined to conference conf1
 
<join id1="p1" id2="conf1"/>

and then play announcement to conference 
 
AS -> MS: request that recorded prompt is played using conference 
 
<dialogstart src="basicivr:playannouncement" conf-id="conf1">
    <data>
       <item name="prompts" value="http://www.example.com/recording1.wav

http://www.example.com/hasjoined.wav"/>
    </data>
</dialogstart>

e. Play "person XX has left the conference' to the conference as a leg
leaves
 
AS -> MS: request prompts played using ivr package
 
<dialogstart src="basicivr:playannouncement" conf-id="conf1">
    <data>
       <item name="prompts"
value="http://www.example.com/recording1.wav
 
http://www.example.com/hasleft.wav"/>
    </data>
</dialogstart>

 
first dtmf dialog listening (only) needs to be activated for host. We
probably need more clarification that this acceptable to the 'join'
topology in the conference package; i.e. that participant's input can be
distributed to multiple sinks.
 
AS -> MS: AS requests a listen-only dialog attached to the host
using the ivr package 
 
<dialogstart src="basicivr:promptandcollect" connection-id="host">
 <data>
  <item name="timeout" value="1080s"/>
  <item name="maxdigits" value="2"/>
 </data>
  <stream media=audio" direction="recvonly"/>
</dialogstart>

MS->AS: MS sends a notification event when host presses dtmf 
 
<event name="dialogexit">
    <data>
       <item name="status" value="1"/>
       <item name="result" value="55"/>
    </data>
</event>
 
and then AS would send mute/unmute commands to all participants using
the conference package 
 
AS -> MS: AS requests participant muted/umuted using conference package
 
<modifyjoin id1="p1" id2="conf1">
 <volume controltype="setstate" value="mute"/>
</modifyjoin>
 
We are looking at defining a 'group' concept in the conference package
so that participants in the conference can be grouped (e.g. all
participants apart from host) and then the modifyjoin command would use
the group id and apply the mute/unmute to all participants in the
group. Saves a lot of AS-MS traffic ...

g. Any participant can hit a DTMF string to mute/unmute his/her own leg
 
 Again in 2 parts: AS activates listener dialog for the participant and
 then when the dtmf notification is received by the AS it can then
 instruct the MS to mute/unmute the participant.

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 18:27
To: [email-masked]; [email-masked]
Subject: RE:
[MEDIACTRL]Fwd:I-DACTION:draft-boulton-conference-control-package-02.txt

Hi Roni,

Gary

Gary,

Roni Even

 and

Then, a few particulars

Thanks.

cheers,

Gary

cheers.
timm

---------- Forwarded message ----------

Send a message to:
        [email-masked].
In the body type:
        "FILE

---

From: <[email-masked]>
Date: Wed, 14 Mar 2007 15:37:18 -0400

Thanks very much for the clear reply, Scott.

Gary

From: McGlashan, Scott [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 2:17 PM
To: MUNSON, GARY A (GARY A); [email-masked]; [email-masked]
Subject: RE:
[MEDIACTRL]Fwd:I-DACTION:draft-boulton-conference-control-package-02.txt

Hi Gary,

And your other questions

[Yes. The prompt would be played to the whole conference. Any
participant who isn't muted is recorded. Frequently, promptandrecord to
a conference is done without a prompt - i.e. record whatever anyone says
on the conference, but the prompt could be used to letpeople know they
are being recorded ...] 

 

thanks

Scott

---- details -----

<dialogstart src="basicivr:promptandcollect" connection-id="con1">
<data>
   <item name="prompts" value="http://www.example.com/accessCode.wav"/
<http://www.example.com/accessCode.wav> >
   <item name="maxdigits" value="4"/>
 </data>
</dialogstart>

 

<dialogstart src="basicivr:promptandrecord" connection-id="p1">
    <data>
       <item name="prompts"  value="http://www.example.com/sayname.wav"/
<http://www.example.com/sayname.wav> >
       <item name="dtmfterm" value="false"/>
       <item name="maxtime" value="30s"/>
    </data>
</dialogstart>

<event name="dialogexit" dialogid="vxi83">
 <data>
  <item name="status" value="1"/>
  <item name="result" value="http://www.example.com/recording1.wav"/
<http://www.example.com/recording1.wav> >
 </data>
</event>

<dialogstart src="basicivr:playannouncement" conf-id="conf1">
    <data>
       <item name="prompts"  value="http://www.example.com/music.wav"/
<http://www.example.com/music.wav> >
       <item name="iterations" value="0"/>
    </data>
</dialogstart>

 

http://www.example.com/hasjoined.wav"/
<http://www.example.com/hasjoined.wav> >
    </data>
</dialogstart>

<dialogstart src="basicivr:playannouncement" conf-id="conf1">
    <data>
       <item name="prompts"
value="http://www.example.com/recording1.wav
                                    http://www.example.com/hasleft.wav"/
<http://www.example.com/hasleft.wav> >
    </data>
</dialogstart>

 

Hi Roni,

Gary

Gary,

Roni Even

 and

Then, a few particulars

Thanks.

cheers,

Gary

cheers.
timm

---------- Forwarded message ----------

Send a message to:
        [email-masked].
In the body type:
        "FILE