[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MEDIACTRL] Direct Phone Call Call-Flow



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