Subject: Re: [MEDIACTRL] Questions for draft-ietd-mediactrl-mixer-control-package

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 15 Feb 2010 10:57:56 -0600

This draft has now completed IETF Last Call. Robert has asked the authors to respond to Henry's comments on the working group mailing list as if they were IETF Last Call comments.

This is the last step before Robert puts this draft on an IESG agenda for balloting, but we need to have responses before Robert does that.

Thanks,

Spencer
  ----- Original Message ----- 
  From: Henry Lum 
  To: [email-masked] 
  Sent: Monday, January 11, 2010 4:33 PM
  Subject: [MEDIACTRL] Questions for draft-ietd-mediactrl-mixer-control-package

  Hi,

  I have a bunch of questions for the mixer control  package:

  -          When <destroyconference> is called, what happens to a dialog that is connected to the conference? It looks like the dialog will receive a <dialogexit> rather than a <unjoin-notify>, but it's a bit unclear in the text in section 4.2.1.3.

  -          Can conference be destroyed automatically when the last participant has left (<unjoin>) from the conference? 

  -          I see that <conferenceexit> has a status code to timeout a conference with a maximum duration, is this system specific?

  -          Can I add my own audio mixing policy by extending the <audio-mixing> type attribute? Looks like I can do this with <video-switch>.

  -          When an automatic mixing is applied with <join>, would <auditresponse> show up as a conference or just a bunch of joins?

  -          I find the wording for <stream> direction to be a bit too much like SDP because the word sendonly implies it's only sending, but at the same time you can also use another <stream> to reference the reverse stream with recvonly. I think we should use plain language like "id1-to-id2", "id2-to-id1", "both", for sendonly, recvonly, and sendrecv, respectively.

  -          For <modifyjoin>, there is one statement that says "It MUST NOT change the configuration of any streams not included as child elements.", but then later in the examples part contradicts with this statement. I actually agree with the example because it's simpler, and that it means a <modifyjoin> changes the entire configuration of the existing join and whatever the child elements defined in modifyjoin will become the new configuration of the join.

  -          Section 4.2.2.5.2 - can we simplify the tones attribute with a default value? For example, the default would be to clamp out all DTMF tones.

  -          Section 4.2.2.5.3 - What is the exact naming of a region? I see that in this draft it's called 1,2,3.., while in the IVR package it is called r1.

  Thanks

  Henry

  CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. 

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

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

---

From: Scott McGlashan <[email-masked]>
Date: Fri, 19 Feb 2010 21:38:05 +0100

Hi Henry,

thanks for the mixer comments and again apologies for my delay in responding. 

The chairs are treating these as IETF Last Call Comments and after satisfactory resolution, we can move onto the next stage.

My response is marked as [SMCG]. For the WG, I've marked proposed spec changes with *** PROPOSED CHANGE. 

Let me know if you need further information or have an issue with a response.

Scott

On 11 Jan 2010, at 23:33, Henry Lum wrote:

> -          When <destroyconference> is called, what happens to a dialog that is connected to the conference? It looks like the dialog will receive a <dialogexit> rather than a <unjoin-notify>, but it’s a bit unclear in the text in section 4.2.1.3.

[SMCG] Right. The dialog is terminated by the MS and a <dialogexit> generated. It isn't clear to me that the mixer spec should talk about dialogs (whereas the IVR spec does talk about conferences). If you think we should add some wording in the IVR spec, please send a suggestion. 

> -          Can conference be destroyed automatically when the last participant has left (<unjoin>) from the conference?

[SMCG] No. The AS needs to explicitly destroy the conference. 

> -          I see that <conferenceexit> has a status code to timeout a conference with a maximum duration, is this system specific?

[SMCG] Yes. The spec doesn't provide a mechanism to set the maximum duration but simply allows an MS to indicate this exit reason.

> -          Can I add my own audio mixing policy by extending the <audio-mixing> type attribute? Looks like I can do this with <video-switch>.

[SMCG] Right. If the MS doesn't understand your type, it can send the appropriate error response.

> -          When an automatic mixing is applied with <join>, would <auditresponse> show up as a conference or just a bunch of joins?

[SMCG] Not quite sure if I get this. If you create a conference it is audited as a conference mixer; otherwise, explicit <join>s as join mixers.

> -          I find the wording for <stream> direction to be a bit too much like SDP because the word sendonly implies it’s only sending, but at the same time you can also use another <stream> to reference the reverse stream with recvonly. I think we should use plain language like “id1-to-id2”, “id2-to-id1”, “both”, for sendonly, recvonly, and sendrecv, respectively.

[SMCG] We didn't have SDP in mind when we came up with the terms originally (probably CCXML). I can see what you mean but I'm not sure that 'id1-to-id2', etc are actually clearer and the values are then different from those used in the IVR package <direction>.  If others on the WG mailing list prefer your suggested terms, then I'll change them. 

> -          For <modifyjoin>, there is one statement that says “It MUST NOT change the configuration of any streams not included as child elements.”, but then later in the examples part contradicts with this statement. I actually agree with the example because it’s simpler, and that it means a <modifyjoin> changes the entire configuration of the existing join and whatever the child elements defined in modifyjoin will become the new configuration of the join.

[SMCG] Good catch. 

*** PROPOSED CHANGE.  <modifyjoin> can affect streams not explicitly mentioned. 

from 

The MS MUST configure the streams that are included within <modifyjoin> to that stated by the child elements. It MUST NOT change the configuration of any streams not included as child elements.

to

The MS MUST configure the streams that are included within <modifyjoin> to that stated by the child elements. 

> -          Section 4.2.2.5.2 – can we simplify the tones attribute with a default value? For example, the default would be to clamp out all DTMF tones.

[SMCG] Sounds reasonable, although it will require a XML schema change! 

*** PROPOSED CHANGE:  Add a default to <clamp>: 

from 
tones:
A space-separated list of the tones to remove. The attribute is mandatory.

to 

tones:
A space-separated list of the tones to remove. The attribute is optional. The default value is "1 2 3 4 5  6 7 8 9 0 * # A B C D" (i.e. all DTMF tones removed).

> -          Section 4.2.2.5.3 – What is the exact naming of a region? I see that in this draft it’s called 1,2,3.., while in the IVR package it is called r1.

[SMCG] Really up to layout to determine the names. I've changed the name in the IVR package from 'r1' to '1'. 

>  
> Thanks
> Henry
>  
> 
> 
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.<ATT00001..txt>

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 22 Feb 2010 07:40:32 -0800

Hi Scott, 

Please see my responses inline.

Henry

[SMCG] Right. The dialog is terminated by the MS and a <dialogexit>
generated. It isn't clear to me that the mixer spec should talk about
dialogs (whereas the IVR spec does talk about conferences). If you think
we should add some wording in the IVR spec, please send a suggestion. 

[HL] IVR spec mentions that status=2 in <dialogexit> means the dialog is
terminated because a conference is terminated so it's clear in the IVR
spec. I just wonder mixer spec should mention this briefly in the last
paragraph of 4.2.1.3.

-          When an automatic mixing is applied with <join>, would
<auditresponse> show up as a conference or just a bunch of joins?

[SMCG] Not quite sure if I get this. If you create a conference it is
audited as a conference mixer; otherwise, explicit <join>s as join
mixers.

[HL] What I mean is that when implicit or automatic mixing is applied
with <join> (as described in 4.2.2.1), there is no actual conference
object created and no conferenceid assigned. In other words, no
conference objects will show up in audit as a result of implicit mixing.

[SMCG] We didn't have SDP in mind when we came up with the terms
originally (probably CCXML). I can see what you mean but I'm not sure
that 'id1-to-id2', etc are actually clearer and the values are then
different from those used in the IVR package <direction>.  If others on
the WG mailing list prefer your suggested terms, then I'll change them. 

[HL] I'm just nitpicking with the choice of names in the attributes
since I find that having id1 and id2 in <join> originated from CCXML
makes understanding the directionality of <stream> a bit confusing. I
actually prefer the directionality defined in the <join> itself like
<join from="id1" to="id2"><stream media="audio" duplex="true"/></join>

The MS MUST configure the streams that are included within <modifyjoin>
to that stated by the child elements. 

[HL] looks good to me

	tones:

	A space-separated list of the tones to remove. The attribute is
optional. The default value is "1 2 3 4 5  6 7 8 9 0 * # A B C D" (i.e.
all DTMF tones removed).

[HL] Looks good to me.

Thanks

Henry

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is
authorized. Any liability arising from any party acting, or refraining
from acting, on any information contained in this e-mail is hereby
excluded. If you are not the intended recipient, please notify the
sender immediately, destroy the original transmission and its
attachments and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.<ATT00001..txt>

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: Scott McGlashan <[email-masked]>
Date: Thu, 25 Feb 2010 18:20:15 +0100

Hi Henry,

I think we're done. 

Expect the updated mixer draft today.

thanks again for your comments. 

scott

On 22 Feb 2010, at 16:40, Henry Lum wrote:

> [HL] IVR spec mentions that status=2 in <dialogexit> means the dialog is terminated because a conference is terminated so it’s clear in the IVR spec. I just wonder mixer spec should mention this briefly in the last paragraph of 4.2.1.3.
>  

[SMCG] I don't plan to add 

> [HL] What I mean is that when implicit or automatic mixing is applied with <join> (as described in 4.2.2.1), there is no actual conference object created and no conferenceid assigned. In other words, no conference objects will show up in audit as a result of implicit mixing.
> 

[SMCG] Ok.

> [HL] I’m just nitpicking with the choice of names in the attributes since I find that having id1 and id2 in <join> originated from CCXML makes understanding the directionality of <stream> a bit confusing. I actually prefer the directionality defined in the <join> itself like <join from=”id1” to=”id2”><stream media=”audio” duplex=”true”/></join>
> 

[SMCG] I'm really reluctant to change at this stage (from an editor perspective). 

> The MS MUST configure the streams that are included within <modifyjoin> to that stated by the child elements. 

[SMCG] Done. 

> A space-separated list of the tones to remove. The attribute is optional. The default value is "1 2 3 4 5  6 7 8 9 0 * # A B C D" (i.e. all DTMF tones removed).

[SMCG] Done.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 25 Feb 2010 11:22:51 -0600

Hi, Scott,

Thank you for the quick update to IVR, and "MIXER" was going to be my next question...

Spencer
  ----- Original Message ----- 
  From: Scott McGlashan 
  To: Henry Lum 
  Cc: [email-masked] 
  Sent: Thursday, February 25, 2010 11:20 AM
  Subject: Re: [MEDIACTRL] Questions fordraft-ietd-mediactrl-mixer-control-package

  Hi Henry,

  I think we're done. 

  scott

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 25 Feb 2010 09:44:25 -0800

Hi Scott,

Thanks - I am okay with the comments.

Henry

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Scott McGlashan
Sent: Thursday, February 25, 2010 12:20 PM
To: Henry Lum
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Questions
fordraft-ietd-mediactrl-mixer-control-package

Hi Henry,

I think we're done. 

scott

Hi Scott,

Henry

 

	[SMCG] Not quite sure if I get this. If you create a conference
it is audited as a conference mixer; otherwise, explicit <join>s as join
mixers.

	[HL] What I mean is that when implicit or automatic mixing is
applied with <join> (as described in 4.2.2.1), there is no actual
conference object created and no conferenceid assigned. In other words,
no conference objects will show up in audit as a result of implicit
mixing.

[SMCG] Ok.

 

[SMCG] I'm really reluctant to change at this stage (from an editor
perspective). 

[HL] looks good to me

[SMCG] Done. 

	tones:

[HL] Looks good to me.

[SMCG] Done. 

Thanks

Henry

 

and/or its affiliated entities.