That said, an intelligent controller should be able to figure out if you allocate the mixer first, then maybe everything should be on the same DSP.
On Aug 11, 2009, at 8:24 AM, Rusu Andreea-B00553 wrote:
Hi,I have been studying the mediactrl drafts lately and I have the following question.Is the scenario described below for a direct phone call valid from the mediactrl framework perspective? This scenario is based on the call flow presented in the draft-ietf-mediactrl-call-flows-01 draft from chapter 6.2.1 Direct Connection.1) AS requests MS to create a media connection for UAC1 using SIP Signaling. 2) MS allocates resources for the UAC1 connection on one DSP device. 3) AS requests MS to create a media connection for UAC2 using SIP Signaling. 4) MS allocates resources for the UAC2 connection on another DSP device (e.g. there is no room left on the previous DSP). 5) AS requests MS to join UAC1 connection with UAC2 connection using the Control Channel. 6) MS can join the connections only if they are located on the same DSP. By reducing the internal media traffic between two DSP devices the I/O processing on the DSP is also reduced thus allowing more external media streams to be handled with the same processing power. So MS decides to move the media connection of UAC1 to the second DSP. In this case the media IP Address and/or the UDP port for the UAC1 connection will change. MS needs to inform AS of this change by sending a re-INVITE. Once the re-Invite is accepted by AS, MS will join the two connections and acknowledge the Join command on the Control Channel.If this is a valid scenario, should it be specified in the standards that the MS can renegotiate the connection settings (maybe also codecs?) after a media connection was already created?Thank you in advance, Andreea Rusu _______________________________________________ MEDIACTRL mailing list MEDIACTRL at ietf.org https://www.ietf.org/mailman/listinfo/mediactrl Supplemental Web Site: http://www.standardstrack.com/ietf/mediactrl
Attachment:
smime.p7s
Description: S/MIME cryptographic signature