Re: [MEDIACTRL] <modifyjoin> for separate stream directions

[Lorenzo Miniero <lorenzo at meetecho.com>]

Hi Elena,

thanks for your feedback, my replies are inline ([LM]).


On Fri, 4 Sep 2009 14:08:46 +0100
"Tebesoi Elena-B10300" <Elena.Tebesoi at freescale.com> wrote:

> Hello all,
>  
> I have a question related to IETF draft <draft-ietf-mediactrl-call-flows-01> and the usage of <modifyjoin>.
> In chapter  6.4.3.  DTMF-driven Conference Manipulation there is presented a message flow.
>  
> First, the message C1 is used to decrease the volume of the sent stream. Then, the message E1 is used to
> increase the volume of the received stream. I understand that E1 message needs to specify also the sendonly stream
> or else the sendonly stream is considered to be inactivated. 
> My question is: why do the settings for the sendonly stream need to be repeated inside the E1 message (the decreasing of the volume) ?
>  
> For an implementor's point of view, this approach introduces overhead in the implementation for both the AS and MS:
> - the AS needs to remember the changed settings and introduce them into the subsequent modifyjoin requests.
> - the MS needs to execute again the actions dictated by the AS even if it already executed some of the requested actions
> or, considering an optimization:
> - the MS needs to analyze the actions requested by the AS and check if it already executed some of them. Besides the extra processing logic required here,
> it is implied that the MS will also remember the change history for each connection.
>  
> Shouldn't the command be applied over the current connection configuration ? In this case it would be enough to mention the
> sendonly stream <stream media="audio" direction="sendonly"/>, to prevent it from beeing inactivated while preserving its previous volume decrease setting.
>  
> The Mixer Control package IETF draft does not clarify this aspect either.


[LM] You're right, specifying the volume again for the unchanged stream
direction (sendonly) is not needed. I checked the mixer draft again and
it is clarified in an example at the end of section 4.2.2.3:

[..]
   The following would change the sendonly
   volume and retain the recvonly stream together with its original
   characteristics such as volume:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <modifyjoin id1="1536067209~913cd14c" id2="conference1">
     <stream media="audio" direction="sendonly">
       <volume controltype="setgain" value="0"/>
     </stream>
     <stream media="audio" direction="recvonly"/>
     </modifyjoin>
   </mscmixer>
[..]

So the draft makes it clear that what is important is maintaining the
directional stream alive, and that the unspecified settings are to be
left untouched. I'll address these considerations in the next version
of the draft. I'll also have to check how we handle this in our
implementation, so I'm glad you pointed this out!



> 
>     
> C1 message:
>     
> "
> ...
>        <stream media="audio" direction="sendonly">
>          <volume controltype="setgain" value="-3"/>
>        </stream>
>        <stream media="audio" direction="recvonly"/>
> ...
> "
>  
> E1 message:
> 
> "
> ...
>        <stream media="audio" direction="recvonly">
>          <volume controltype="setgain" value="+3"/>
>        </stream>
>        <stream media="audio" direction="sendonly">
>          <volume controltype="setgain" value="-3"/>
>        </stream>
> ...
> "


[LM] Yes, the more correct E1 message should be:


        <stream media="audio" direction="recvonly">
          <volume controltype="setgain" value="+3"/>
        </stream>
        <stream media="audio" direction="sendonly"/>


Increase the volume of the incoming stream, and keep the outgoing
stream as it is. Of course, the way it is now in the draft is not
wrong, it's just more verbose than it should be.


Thanks for the feedback, please let us know if you find anything else
confusing in our draft.

Lorenzo

> 
> Elena Tebeşoi 
> 
> Software Engineer
> 
>  
> 
> Freescale Semiconductor Romania
> 
>  
> 
> [ x ]  Public
> 
> [  ] Freescale Semiconductor Internal Use Only
> 
> [  ] Freescale Semiconductor Confidential Proprietary
> 
>  
> 


-- 
Lorenzo Miniero <lorenzo at meetecho.com>