That's a fair statement. But I see that MEDIACTRL architecture RFC does state the following in Section 6.4: Floor control-
In case the session has been previously updated with a 'sendonly' associated to the media stream, the MS must originate a further re-INVITE stating that the media stream flow is now bidirectional ('sendrecv').
And AS has to make sure that the media control mechanisms do not override the floor control in a conference.
Hope its not out of context.
thanks,
Padma
This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. •
-----Eric Burger <eburger at standardstrack.com> wrote: -----
To: Padma Valluri/ESI/CSC at CSC
From: Eric Burger <eburger at standardstrack.com>
Date: 08/12/2009 10:10PM
cc: mediactrl at ietf.org
Subject: Re: [MEDIACTRL] Direct Phone Call Call-Flow
I would offer that SIP is SIP; the media server can do whatever it
wants. I would also offer that directing the media server to do this
renegotiation is beyond the scope of the current charter of MEDIACTRL.
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
>