On Aug 12, 2009, at 2:34 PM, Padma Valluri wrote:
I think the media server should have the capability to re-negotiate the media resources mid call. I can't think of any applications/ scenarios right now, but wondering if this requirement has a broader scope than conferencing.thanks, Padma -----mediactrl-bounces at ietf.org wrote: ----- To: Rusu Andreea-B00553 <Andreea.Rusu at freescale.com> From: Eric Burger <eburger at standardstrack.com> Sent by: mediactrl-bounces at ietf.org Date: 08/12/2009 06:52AM cc: mediactrl at ietf.org Subject: Re: [MEDIACTRL] Direct Phone Call Call-Flow I could see something like this as part of an advanced conferencing package. However, I would offer it is out of scope for the current IVR and MIXER packages. Any thoughts from the rest of the work group? On Aug 12, 2009, at 5:46 AM, Rusu Andreea-B00553 wrote: > Hi, > > I do agree with you that MEDIACTRL should not address the DSP> allocation/management business. The Media Server alone is responsible> with this. > > What I am suggesting is to allow the Media Server to renegotiate the > connection settings (maybe even codecs) for a certain media > connection. > For example, if one connection was created with an INVITE received > from > AS, later on the MS should be able to send a re-INVITE for the same > connection to change the IP address or UDP port on his side. > > There may be situations when the Media Server needs to perform > internally some resources re-allocations (for load balancing or for > optimizations) which would require changes in the connection > settings of > a certain media connection (the scenario presented in the initial > email> is such an example). Another plausible scenario is when one DSP stops> and the Media Server is recovering by restoring the media > connections to> a new DSP (another network entity). This could have the side effect of> changing the IP addresses of the restored connections. >> With H.248 the context is first created and then the terminations are > added to that context. So the Media Gateway could easily allocate the> terminations belonging to the same context on the same network > resource. > > With MEDIACTRL the media connections are created first and then they > are > joined together or with a mixer. Even if the mixer is created before > the > media connections, as far as I know, there is no way for the Media > Server to know that the media connections will be joined later with > that > mixer or another. > So, I do agree that the AS should not tell MS where to create the > connections but in case MS needs to move some connections internally > from one network entity to another it should be able to announce the > AS > of this change. > > The MEDIACTRL standards are not forbidding or allowing the > renegotiation > (re-INVITE) of a media connection by a Media Server. I believe this > could create interoperability problems and it would be useful to be > clarified. > > > Andreea Rusu > > -----Original Message----- > From: Eric Burger [mailto:eburger at standardstrack.com] > Sent: Tuesday, August 11, 2009 9:26 PM > To: Rusu Andreea-B00553 > Cc: mediactrl at ietf.org > Subject: Re: [MEDIACTRL] Direct Phone Call Call-Flow > > Step 6 is totally behind the curtain. MEDIACTRL explicitly will not > get > to the DSP allocation / management business. Even H.248 will not > allow > for that level of control. > > 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 > _______________________________________________ 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