Subject: [MEDIACTRL] Updated Mixer control package -04

From: "McGlashan, Scott" <[email-masked]>
Date: Tue, 27 Jan 2009 11:09:11 +0000

We've updated the Mixer control package to version 04: http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-mixer-control-package-04.txt. The differences with version 03 are shown in the attached diff document. The list of changes are shown below. 

Two issues were raised in the security review which we've not yet addressed:

[1] Do the authors believe that RTP should be mentioned in this section and a reference to securing these sessions?

This issue also applies to the IVR package. I can see value in adding a statement that RTP should be secured and we should also add text about securing the SIP connection too: i.e. a connection's SIP and RTP transport should be secured. I know the framework covers securing SIP in setting up the control channel, but packages would benefit from a statement about securing the connection iteself.

Any objections/thoughts?  

[2]  4.2.1.4.3.1. Priority assignment. It seems that the default priority value of 100 is arbitrary.  Why not make the default 0 (zero), which would be undefined, with the highest priority at 1 (one), etc.?

I'm not sure if they is anything to be gained by changing the priority assignment default. If it was changed, then the priority value would become an integer with negative and positive values and same rule of 'the lower the value, the higher the priority' would apply except this time the negative integer values would be allowed. 
 
If there are other issues please let us know.

Thanks

Scott

   The following are the changes between the -04 and -03 versions.

   o  4.2.1.4.3: corrected typo

   o  4.2.2.3: Clarified the behavior of <modifyjoin> for cases where
      each direction of a stream is independently controlled.

   o  4.2.2.5: Corrected syntax error in examples.

   o  4.2.2.5.1: Clarified that when an audio stream is in the muted
      state, then a <volume> automatic or setgain control causes the
      state to change automatically to unmuted.

   o  7 Security: Clarified that both conference and join mixers are
      covered by the package security policies.

   o  7 Security: Added a denial of service example where the attacker
      impersonates the MS.

   o  7 Security: Clarified that the package security policy for
      multiple channels is only useful if the channels themselves are
      secured.

   o  Updated acknowledgements.

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

---

From: Eric Burger <[email-masked]>
Date: Tue, 27 Jan 2009 17:56:15 -0500

inline, as participant

On Jan 27, 2009, at 6:09 AM, McGlashan, Scott wrote:

> We've updated the Mixer control package to version 04: http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-mixer-control-package-04.txt 
> . The differences with version 03 are shown in the attached diff  
> document. The list of changes are shown below.
>
> [1] Do the authors believe that RTP should be mentioned in this  
> section and a reference to securing these sessions?
>
> This issue also applies to the IVR package. I can see value in  
> adding a statement that RTP should be secured and we should also add  
> text about securing the SIP connection too: i.e. a connection's SIP  
> and RTP transport should be secured. I know the framework covers  
> securing SIP in setting up the control channel, but packages would  
> benefit from a statement about securing the connection iteself.
>
> Any objections/thoughts?

Cannot hurt, even if only to say, "You really need to secure the  
signaling and media; see the Framework for more on the topic."

> [2]  4.2.1.4.3.1. Priority assignment. It seems that the default  
> priority value of 100 is arbitrary.  Why not make the default 0  
> (zero), which would be undefined, with the highest priority at 1  
> (one), etc.?
>
> I'm not sure if they is anything to be gained by changing the  
> priority assignment default. If it was changed, then the priority  
> value would become an integer with negative and positive values and  
> same rule of 'the lower the value, the higher the priority' would  
> apply except this time the negative integer values would be allowed.

I agree. When I saw the comment, my thought was, "yuck - instead of  
arbitrary integer comparisons, we get arbitrary floating-point  
comparisons." It is all arbitrary to me :-)