Subject: [MEDIACTRL] Direct Phone Call Call-Flow

From: "Rusu Andreea-B00553" <[email-masked]>
Date: Tue, 11 Aug 2009 13:24:28 +0100

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

---

From: Eric Burger <[email-masked]>
Date: Tue, 11 Aug 2009 14:25:47 -0400

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:

> 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.
>     3) AS requests MS to create a media connection for UAC2 using  
> SIP Signaling.
>     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.
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

---

From: "Rusu Andreea-B00553" <[email-masked]>
Date: Wed, 12 Aug 2009 10:46:18 +0100

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:[email-masked]] 
Sent: Tuesday, August 11, 2009 9:26 PM
To: Rusu Andreea-B00553
Cc: [email-masked]
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.

---

From: Eric Burger <[email-masked]>
Date: Wed, 12 Aug 2009 06:52:27 -0400

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:

> get
> you

---

From: Padma Valluri <[email-masked]>
Date: Wed, 12 Aug 2009 14:34:24 -0400

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

[email-masked] wrote: -----

To: Rusu Andreea-B00553 <[email-masked]>
From: Eric Burger <[email-masked]>
Sent by: [email-masked]
Date: 08/12/2009 06:52AM
cc: [email-masked]
Subject: Re: [MEDIACTRL] Direct Phone Call Call-Flow

---

From: Eric Burger <[email-masked]>
Date: Wed, 12 Aug 2009 22:10:18 -0400

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
>
> SIP
> SIP

---

From: Padma Valluri <[email-masked]>
Date: Thu, 13 Aug 2009 12:13:06 -0400

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 <[email-masked]> wrote: -----

To: Padma Valluri/ESI/CSC@CSC
From: Eric Burger <[email-masked]>
Date: 08/12/2009 10:10PM
cc: [email-masked]
Subject: Re: [MEDIACTRL] Direct Phone Call Call-Flow