Subject: RE: [Megaco] one dount on RFC3015 as to the requirement on RFC280 5

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 2 Jan 2002 08:18:01 -0500

You audit the Media descriptor of all of the terminations
to determine which terminations are employing the
codec of interest.

Brian

> -----Original Message-----
> From: zhangzhong [mailto:[email-masked]]
> Sent: Friday, December 28, 2001 9:25 PM
> To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Shashi Kumar'
> Cc: [email-masked]
> Subject: Re: [Megaco] one dount on RFC3015 as to the requirement on
> RFC2805
> 
> 
> Hi Brian,  All
> I agree with you on the concept of Audit capability and Audit 
> Value . But in present protocol , How can we get the 500 busy 
> through Audit value present defined, I can't find the 
> parameter or package defined the case. 
> 
> Regards
> Zhangzhong
> 
> ----- Original Message ----- 
> From: Rosen, Brian <[email-masked]>
> To: 'Madhu Babu Brahmanapally' <[email-masked]>; 
> 'Shashi Kumar' <[email-masked]>; 'zhangzhong' 
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, December 29, 2001 12:54 AM
> Subject: RE: [Megaco] one dount on RFC3015 as to the 
> requirement on RFC2805
> 
> 
> > Audit capabilities tells you what the capabilities of the system
> > are.  Audit Value tells you what is currently "in use".
> > In theory, the "1000 G.711 channel resource" comes from Audit
> > Capability, "500 busy" comes from Audit Value.
> > 
> > In general, the RFC is compliant with the requirements with one
> > notable exception: many gateways are implemented with DSPs or other
> > programmable resources. There is no good way to express capability
> > with such resources.
> > 
> > If you have 1000 fixed G.711 channels, Audit Capability will reveal
> > that.  If 500 channels are used, Audit Value will reveal that.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Madhu Babu Brahmanapally [mailto:[email-masked]]
> > > Sent: Friday, December 28, 2001 9:44 AM
> > > To: 'Shashi Kumar'; 'zhangzhong'
> > > Cc: [email-masked]
> > > Subject: RE: [Megaco] one dount on RFC3015 as to the 
> requirement on
> > > RFC2805
> > > 
> > > 
> > > HI Shashi,All,
> > > Its true that Audit will help MGC to reconcile the 
> > > inconsistency. But for
> > > the specific scenario Zhang has pointed, How this resource 
> > > information is
> > > exchanged between the MG and the MGC. According to my 
> > > knowledge there is no
> > > parameter or anything as such to "quantitatively" identify 
> > > G711 or any such
> > > channel resource.
> > > Regards
> > > Madhubabu
> > > 
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > > Shashi Kumar
> > > Sent: Thursday, December 27, 2001 11:55 PM
> > > To: zhangzhong
> > > Cc: [email-masked]
> > > Subject: Re: [Megaco] one dount on RFC3015 as to the 
> requirement on
> > > RFC2805
> > > 
> > > 
> > > we have provision to audit the MG resource, which 
> clearlty defined by
> > > Megaco/H.248. By means of Auduting the MG resources we can always
> > > "reconcile inconsistencies between the MGC and the MG"
> > > 
> > > thanks,
> > > shashi
> > > 
> > > 
> > > > zhangzhong wrote:
> > > >
> > > > Hi :
> > > > In the rfc 2805, there have a request to H.248:
> > > >         Provide a mechanism to discover the current available
> > > > resources
> > > >         in the MG, where resources are dynamically consumed by
> > > >         connections and the MGC cannot reasonably or 
> reliably track
> > > > the
> > > >         consumption of such resources. It should also 
> be possible to
> > > >         discover resources currently in use, in order 
> to reconcile
> > > >         inconsistencies between the MGC and the MG.
> > > >
> > > > This means MGC can know the resource consume in the MGW , 
> > > for example
> > > > , if There have 1000 G.711 channel resource , if 500 is 
> > > busy , How can
> > > > MGC know this through RFC3015?
> > > > If can't , The RFC3015 is inconsist with the RFC2805
> > > >
> > > > Thanks for the reply.
> > > > Regards
> > > > Zhangzhong
> > > 
> > > 
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/megaco
> > >
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 2 Jan 2002 08:23:26 -0500

I agree that when the expression of available and consumed
resources is not a simple count, then the audit mechanisms
in 3015 are inadequate.  This is actually a limitation of
SDP and the Annex C equivalent of it.  There is work to extend
SDP, which may have more facilities to assist this problem.

Please note that the problem is quite complex, and it isn't
clear to me that there exists any straightforward way for
the MG to express capability and consumed resources in a
manner that the MGC can always predict whether a new
Add or Modify will work.

Brian

> From: Raju [mailto:[email-masked]]
> Sent: Monday, December 31, 2001 9:56 AM
> To: zhangzhong; Madhu Babu Brahmanapally
> Cc: [email-masked]
> Subject: RE: [Megaco] one dount on RFC3015 as to the requirement on
> RFC2805
> 
> 
> I do agree with Zhangzhong.
> 
> Infact calculation of available resources by MGC becomes more 
> tough and
> ambigous if the GW supports more than one codec
> (e.g. G.723 and G.711), which is generally be the case.
> The number of available G.711 codecs depends on the number of 
> G.723 codecs
> in use, as G.723 uses more MIPS.
> MGC can't understand these dependencies and calculate the 
> exact number of
> free resources available, only MG
> knows how eactly to calculate the free or available resources.
> 
> Pls read my previous mail below.
> 
> Thanks
> Raju
> 
> > zhangzhong
> > Sent: Friday, December 28, 2001 9:17 PM
> > To: Madhu Babu Brahmanapally; 'Shashi Kumar'
> > Cc: [email-masked]
> > Hi all,
> > 1  I think the method below can  reach the aim in theory , It is
> > a idea in the present protocol, but not very good. And Because it
> > is very ambiguous . It will introduct the difficulity of
> > interwork between MGC and MGW with more difficulity. If the MGW
> > has a big capability , the management of these termination 
> has problems .
> > The method is not the idea of MEGACO, because  operations of
> > sending tone or playing announcemnt  are all done on  the same
> > termination which receive/send media from/to outside not specified.
> >
> >
> > Thans for your reply and help.
> > Regards
> > Zhangzhong
> >
> >
> > Hi Zhangzhong,
> > as of current understanding we should admit that there is 
> no direct was
> > of doing, but we have the information with in the Megaco scope to do
> > this.
> >
> > we shall take your specific example of G.711 resource issue...
> > 1. Each G.711 resource is identified as a Termination 
> (using Termination
> > ID), which is a provisioned info( or otherwise)
> > 2. At any Given point of time, you know how many 
> termination's are in
> > (a) context(s) ( in both MG and MGC instance of protocol), 
> which shall
> > be take as G.711 resource which is busy....
> >
> > with the above info it is very easy to identify how many of G.711
> > resource are free...
> >
> > hope this helps...
> >
> > shashi
> >
> >
> >
> >
> > From: Madhu Babu Brahmanapally <[email-masked]>
> > To: 'Shashi Kumar' <[email-masked]>; 'zhangzhong'
> > <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Friday, December 28, 2001 10:44 PM
> > Subject: RE: [Megaco] one dount on RFC3015 as to the requirement
> > on RFC2805
> >
> >
> > > HI Shashi,All,
> > > exchanged between the MG and the MGC. According to my knowledge
> > there is no
> > > parameter or anything as such to "quantitatively" identify G711
> > or any such
> > > channel resource.
> > > Regards
> > > Madhubabu
> > >
> > > > This means MGC can know the resource consume in the MGW 
> , for example

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 2 Jan 2002 08:23:26 -0500

Brian

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 2 Jan 2002 14:41:19 -0500

If I summarize your argument, it is that the MGC should not try to manage
the raw resources (e.g. DSP MIPS) on the MG, but should have available
normalized estimates of gross capacity.  The most straightforward way of
achieving this is to define a package with the appropriate properties on
ROOT.  The technicalities of how you would define the properties (in terms
of simultaneous and alternative capabilities) are rather complex, but the
package mechanism would let us hive off the work.

-----Original Message-----
From: Raju [mailto:[email-masked]]
Sent: Monday, December 31, 2001 9:56 AM
To: zhangzhong; Madhu Babu Brahmanapally
Cc: [email-masked]
Subject: RE: [Megaco] one dount on RFC3015 as to the requirement on
RFC2805

Infact calculation of available resources by MGC becomes more tough and
ambigous if the GW supports more than one codec
(e.g. G.723 and G.711), which is generally be the case.
The number of available G.711 codecs depends on the number of G.723 codecs
in use, as G.723 uses more MIPS.
MGC can't understand these dependencies and calculate the exact number of
free resources available, only MG
knows how eactly to calculate the free or available resources.

Thanks
Raju

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> zhangzhong
> has a big capability , the management of these termination has problems .
> as of current understanding we should admit that there is no direct was
> 1. Each G.711 resource is identified as a Termination (using Termination
> 2. At any Given point of time, you know how many termination's are in
> (a) context(s) ( in both MG and MGC instance of protocol), which shall
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Shashi Kumar
> > we have provision to audit the MG resource, which clearlty defined by
> > >         connections and the MGC cannot reasonably or reliably track
> > > the
> > >         consumption of such resources. It should also be possible to
> > >         discover resources currently in use, in order to reconcile
> > > This means MGC can know the resource consume in the MGW , for example
> > > , if There have 1000 G.711 channel resource , if 500 is busy , How can

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 2 Jan 2002 14:41:19 -0500

-----Original Message-----
From: Raju [mailto:[email-masked]]
Sent: Monday, December 31, 2001 9:56 AM
To: zhangzhong; Madhu Babu Brahmanapally
Cc: [email-masked]
Subject: RE: [Megaco] one dount on RFC3015 as to the requirement on
RFC2805

Thanks
Raju

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Jan 2002 08:13:59 -0500

Because the general problem is very complex, and no one has
proposed a general solution that seems likely to cover most
cases.

As an example, many systems are implemented with DSPs.  These
systems have very complex interaction between how many codecs
of different types can be in use simultaneously.  A system might,
for example, support 16 channels of G.729, 32 channels of G.711
and 32 channels of G.165 echo cancel with 64 ms tails, but
not simultaneously.  It may be that if you have one channel of
G.729, then you can support another 27 channels of G.711, and
if you have any G.729, then the longest tail is reduced.
This is because there are actually several variables at work -
DSP MIPs, and memory capacity, and the interaction between those
variables is complex.  I once discussed having a language which
allowed you to express this kind of thing, but it was too complex
for most people to deal with.  Then you add spares issues and
things get even more complex.

The other side of this issue is that the MGC can ask for resources
on the MG, and the MG can fail if there are no more resources.
This can be done in a way that lets the MGC either try to reroute
the call, or supply the appropriate error message to the caller.
That is why we didn't worry more about this known limitation.

Brian

> Sent: Friday, January 04, 2002 4:08 AM
> To: Rosen, Brian
> Cc: [email-masked]
> Hi Brian,
> Yes , It can know the resource using, But if you can't 
> binding all channel with Termination, How can you know the 
> status of left? idle or failed? 
> We can configure the Max number of channel and we can know 
> the exact number of them is busy, but we can't know the 
> status of spares . We can bind a termination with one 
> channel, and put into NULL context, Only in this case, when 
> one channel failed, MGW report the status to MGC .
> But this method , I think , is not a standard way .
> Why not define a explicit way to reach the aim?
> 
> Regards
> Zhangzhong
> 
> To: 'zhangzhong' <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, January 02, 2002 9:18 PM

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 7 Jan 2002 09:04:44 -0500

Your proposal is a bit against the Megaco philosophy.  Megaco tells the MG
what results are required and leaves it up to the MG to manage its internal
resources to get those results.  In older technology conferencing required a
dedicated resource, in the way you suggest, but these days my understanding
is that everything is done by DSPs.  Conferencing just requires the loading
of a little more software and the allocation of more memory and CPU time.

Your remarks on handoff make me suspect there are some requirements to be
looked at before we consider a detailed solution.  I assume you are saying
that in both the handoff and conferencing cases you may have three
terminations in the context, but in the handoff case two of the terminations
represent the same user.  What sort of behaviour are you then expecting from
the MG?  Why do you need two terminations to represent the user being handed
off?

-----Original Message-----
From: zhangzhong [mailto:[email-masked]]
Sent: Friday, January 04, 2002 10:45 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [Megaco] one dount on RFC3015 as to the requirement on
RFC2805

Hi Brian, all
Ok, This problem will discuss later after having a way.
Another problems, could you answer to me , thanks .
Why not define a explicit way to apply the conference resource ?
How can MGW know when to activate conference resource ?
How can MGC know whether a MGW have the conference resource or not? If
through configuration, How does MGC maintain the dynamic status of
conference resource when it is bad or restrore?
If through the max number in one context , it is no problem in fixed network
, but in mobiles cases, HandOver will introduce more than two termination
into one context.

Regards
Zhangzhong

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 7 Jan 2002 09:04:44 -0500

-----Original Message-----
From: zhangzhong [mailto:[email-masked]]
Sent: Friday, January 04, 2002 10:45 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [Megaco] one dount on RFC3015 as to the requirement on
RFC2805

Hi Brian, all

Regards
Zhangzhong

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 7 Jan 2002 09:30:51 -0500

Well, the door is, at least in theory, open to add features in
V2.  I actually oppose doing this, but there are some who feel
that tinkering with the protocol before there is any substantial
deployment experience is a good idea.

You could propose a solution.  If you do, I think you would want
to see if it works for a wide variety of resource models that MGs
might implement, and yet be simple enough that a really small
phone or gateway could implement it without a lot of code.

The answer to your question is that if the MGC knows the MG has
a capability for something, but gets an error when it tries to
use it, then it could, when a future requirement arises for that
capability, ask for it again.  It will either work, or fail
again.  No need to poll.

Brian

> Sent: Friday, January 04, 2002 10:40 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Yes , It has problems about this. I think there should have 
> some methods resolving them. 
> And If we can't resolve these problems, There will introduce 
> more difficulity of interworking between different company's 
> product  and low the efficiency of network.
> Problems:
> MGW can reject the resource command from MGC, OK, It is no 
> problems. But how MGC know the resource in this MGW is 
> available again?  We can  setup a flag , and apply the 
> request periodicly, when success, reset the flag, or start a 
> timer , after the timer time out , reset the flag. etc.
> All these methods will introcude much traffic between MGC and 
> MGW. It is not good for the network resource management in the MGC. 
> 
> Regards
> Zhangzhong
> 
> 
>