Subject: RE: physical vs. ephemeral terminations

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 27 Feb 2001 14:10:49 -0500

> I'm working on a socalled 'Interior' Media Gateway (IMG). 
> Basically its
> function is to interwork incompatible media formats. It sinks media
> streams from calling SIP/H.323 terminals, re-encodes the audio and/or
> video into another format and then ships the results to the called
> SIP/H.323 terminals.
> (Example: the audio stream of a UMTS terminal equipped with the newly
> defined 'AMR' codec talking to an H.323 terminal equipped 
> with a 'G.711'
> codec will go through such transcoder, else communication would not be
> possible.)
No problem, appropriate use of Megaco

> Such IMGs have nothing but ephemeral terminations. Realisation is by
> means of dsp boards only (apart from some common functions such as a
> Megaco itf and a packet/cell network interface). Each dsp 
> boards offers
> some 64 (worst case) to 256 (best case) ephemeral terminations. Be
> carefull, this is not a static figure ie the needed dsp 
> processing power
> is dependent on what media input formats must be transcoded into what
> output formats and also whether or not associated media 
> streams (such as
> video + associated audio) must be retimed (using the transcoder clock)
> and foreseen with new sequence numbers in order to allow the receiving
> terminal to playback in a lip synchronous way.
No problem, it's clearly one of the scenarios we imagined when we
defined ephemerals

> Now, I install such an IMG, switches on the power, the IMG sets up a
> UDP/IP connection, then registers with its MGC (with a 
> ServiceChange on
> root), the MGC recognises and admits the IMG, and..... I go 
> happily home
> being sure that I have extended the network with a new pool of some
> hundreds/thousands of transcoders.
> But the reality is different. I may have forgotten to plug in the dsp
> boards or somebody may have placed the wrong version of boot 
> prom on the
> boards such that none start up,...... or many other possible
> installation and equipment faults may have occurred resulting 
> in having
> extended the network with exactly NOTHING. In other words, the network
> has no new pool of transcoders and nobody knows about it because IMG
> will not send any additional ServiceChange to MGC to report the
> ephemeral termination failures. 
Well, there are a few ways you COULD use to indicate this.

> 
> People in my environment find this bad design.
> Maybe I'm missing something, but let me ask some questions in 
> trying to
> improve this design or..... to convince my environment that 
> this is how
> the standard has specified things.
> 
> /1/. Is above description about ServiceChange the correct 
> interpretation
> of the Megaco standard version 1 ?
Well, yes, but I think that's not the WHOLE truth.
One thing is that when the MG booted bad, the first state of the MG is
all (or half) the transcoders are not there.  You wouldn't get a
serviceCHANGE
(Megaco is case independent!) message.  Nothing changed.
If you were expecting one, are you expecting a serviceChange on every
termination that is good after boot?  You don't get such a thing.
That's why you Audit after you establish a control association.

> 
> /2/. In case answer to /1/ is YES, was it specified the way it is now
> 'intentionally', or are there plans to 'modify' some of it ? (Reading
> this thread I feel that there is no concensus about it.)
I am, of course, supporting the idea that ServiceChange is allowed on
ephemerals.

> 
> /3/. In case answer to /1/ is NO, what ServiceChange can IMG send to
> MGC.
> Let's take a simple case :
> -the IMG in example contains two dsp boards, first board 
> fails to boot,
> second board is in service;
> -no ephemerals are created;
> -each dsp board can create between 64 and 256 ephemerals (this is
> 'dynamically' controlled by IMG and is dependent an requested tasks);
> -packages implemented are : g, root, nt and rtp (but this is maybe not
> relevant for this example)
> -the MGC and IMG design are mutually unknown, therefor we must assume
> that there are no naming conventions amongst each other for the
> Terminations.
I think that's a poor choice, but I can stay with it for a while

> 
> QUESTION : what value must IMG put in parameter TerminationID when it
> wishes to send a ServiceChange command to the MGC related to 
> the out of
> service state of all ephemeral terminations on the first dsp board ? I
> think IMG cannot even come up with anything. Correct ?
Unless we support ServiceChange on non-existant ephemerals, yes

> 
> /4/. I also wish to come back on the Audit issue.
> There was a concensus -earlier in this thread- that Audit on 
> ephemerals
> (ALL) is legal and makes sense.
I'll let our esteemed chair (Tom) pass on whether we have consensus that you
can audit a wildcarded ephemeral.  I think we must.

> Let's take exactly the same example as in /3/ above, if MGC wanted to
> know everything about the service state of the terminations 
> in the IMG :
> 
> QUESTIONS : 
> -what Audit command should MGC send ? 
Here I'd suggest that for both Audit and ServiceChange, that the
best design is to name the ephemerals so that wildcards work for you.
Therefore, if you have two boards, you might call the ephemerals on
one board bd1/* and the ephemerals on the other bd2/*.
Then you can say
W-AuditCapability=bd1/*{Audit{media}}

> -assume the latter command specifies contextID=ALL, TerminationID=ALL,
> and AuditDescriptor{Media}; what TerminationIDs would IMG 
> insert in the
> reply ? The best IMG can come up with is that half of the terminations
> have servicestate "inservice", and the other half have servicestate
> "outofservice". IMG cannot 'name' the terminations and can also not
> 'number' them.
> After all, the IMG has here exactly the same problem as in the
> ServiceChange case : it cannot define the terminationIDs.
> Correct ?
In your example, there is a finite maximum number of ephemerals per board,
so in fact you could return values for each of them.  Note you need to 
use auditCapability, not auditValue.

Remember, we are assuming we CAN auditCapability non-existant ephemerals

> -assume the latter command specifies contextID=ALL, TerminationID=ALL,
> and an (empty) AuditDescriptor{}.
> According para 7.2.5 of Megaco standard this must return the
> terminationID. What TerminationIDs would IMG insert in the 
> reply ? Again
> I think IMG cannot return anything....... despite statements 
> like "an MG
> knows the range of ephemerals it can create".
Same answer

> Pools of ephemerals are no longer specific for one single function but
> are now multifunctional which offers great system flexibility 
> and avoids
> complex dimensioning problems.
> Ephemeral termination IDs can only be determined when also 
> other -stream
> specific !- properties are know. These, unfortunately, are only known
> when streams are created. This brings me to the conclusion that
> non-created ephemerals cannot be audited -at least not for 
> what concerns
> the terminationID-.
On the contrary, I think they can.  At least I think you can do
auditCapabilities. 
 
> 
> /5/. Sofar -I think- my IMG design cannot be improved neither with
> ServiceChange, nor with AuditCapabilities. I'm not in favor of
> AuditCapabilities because IMG cannot control these 
> procedures. Moreover,
> the standard does not enforce it and MGC may therefor not run them.
> A third way, however, to improve the IMG design is to make a different
> Megaco Model of the IMG : instead of defining the terminations as
> ephemerals, I could define them as physical terminations. I 
> agree that I
> then loose all the flexibility offered by the concept of ephemerals, I
> also do not know yet how exactly I can dimension the IMG to 
> everybody's
> satisfaction, but the terminations will be provisioned in the 
> IMG, they
> will have fixed/defined IDs and ServiceChange to notify MGC about
> termination failures will be possible and MGC will understand the
> ServiceChange command.
> Good idea ?
No

> By the way, when and why exactly does one chooses for the physical or
> the ephemeral model? Everything is physical after all.
I usually think that if you can point into the hardware and find a
wire/trace
that represents one termination, then it's a physical.  If you can't, then
it's
ephemeral.  Some think physicals have external interfaces, but I don't think
that
way (you could model, for example, a DSP implemented conference bridge that
had
a fixed number of ports as physical terminations).

> 
> /6/. Because I think /5/ is a bad idea, I have a fourth option.
> I simply make the statement that the "unfortunate IMG installation"
> which I did in my example has nothing to do with Megaco ServiceChange
> procedures, nor with Megaco Audit procedures, but must be reported
> through other channels (like SNMP) towards an Operations&Maintenance
> Center ? After all, the IMG is a network element.
> If this is the right answer to my socalled bad IMG design I can now
> forget everything about (impossible) ServiceChanges and Audits on
> ephemerals.
Yes, you can do that.

> 
> Thanks,
> Willy
> 
> > Tom-PT Taylor wrote:
> > 
> > I never thought about it up to now -- I tended to think of single
> > terminations going out of service.  What context would the action
> > containing the ServiceChange for a group of terminations show?
> > 
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: Thursday, February 22, 2001 8:53 AM
> > > To: Boyle, Kevin [NCRTP:3Z70:EXCH]; Madhu Babu Brahmanapally
> > > Cc: 'Willy Reheul'; 'megaco'
> > > Subject: RE: physical vs. ephemeral terminations
> > >
> > >
> > > The reason you want to execute a service change against
> > > an ephemeral is to notify the MGC that the network
> > > interface is down, and it can no longer ask the MG
> > > to create that range of ephemerals.  That is the
> > > point of ServiceChange - terminations out of service.
> > >
> > > Yes, you can get an error when you try.  We could have
> > > done that for physical terminations.  However, we
> > > believed it useful for the MG to tell the MGC in
> > > advance that terminations are being taken out of
> > > service.
> > >
> > > In the same light, you want to be able to AuditCapabilities
> > > of these terminations, so that you can discover, in
> > > advance of attempting an Add/Modify, what capabilities
> > > the terminations have.  You could try it and get an error,
> > > but that might be a hard way to find out what ephemerals
> > > the MG supports!
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Kevin Boyle [mailto:[email-masked]]
> > > > Sent: Wednesday, February 21, 2001 4:27 PM
> > > > To: Madhu Babu Brahmanapally
> > > > Cc: 'Willy Reheul'; 'megaco'
> > > > Subject: Re: physical vs. ephemeral terminations
> > > >
> > > >
> > > > Unless the MGC explicitly audits looking for ephemeral
> > > > terminations, the MGC
> > > > has NO idea about them until such time as they are created.
> > > > ServiceChanges on
> > > > ephemerals sounds like a bad idea, as it could be confusing
> > > > to the MGC.
> > > >
> > > > Further, Why would you want/need to perform ServiceChanges on
> > > > ephemerals?
> > > > There are error codes in existence for denoting that a MG is
> > > > in service but not
> > > > able to comply with requests due to resource limitations.
> > > > Ephemerals would
> > > > fall under that category, IMHO.
> > > >
> > > > Kevin
> > > >
> > > > Madhu Babu Brahmanapally wrote:
> > > >
> > > > > HI Willy,
> > > > > Yes this sounds correct and should be legal. Since when the
> > > > MG registered
> > > > > itself with MGC ..it is a common understanding  what
> > > > physical and ephemeral
> > > > > terminations are present in the MG. If the board with
> > > some physical
> > > > > terminations go out, service change is generated for all of
> > > > them. This is
> > > > > true for ephemeral terminations also.
> > > > >
> > > > > Best Regards.
> > > > > Madhubabu
> > > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of
> > > Willy Reheul
> > > > > Sent: Wednesday, February 21, 2001 1:25 PM
> > > > > To: megaco
> > > > > Subject: Re: physical vs. ephemeral terminations
> > > > >
> > > > > Continuing with the same line of thinking ( ".....A MG
> > > > knows what is the
> > > > > range of ephemeral termination that it can create, etc.
> > > > ......" ) can
> > > > > one then also assume that a Media Gateway shall send a
> > > > ServiceChange to
> > > > > its MGC when boards that realise these ephemeral terminations
> > are
> > > > > going/taken out of service or return to in service, 
> even when NO
> > 
> > > > > ephemerals are created on them ?
> > > > > Or can Media Gateways only do that when ALL ephemerals are
> > > > affected by
> > > > > the ServiceChange ?
> > > > >
> > > > > thanks,
> > > > > Willy.
> > > >
> > >
>

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Tue, 27 Feb 2001 17:04:28 -0500

HI all,
The Audit Capability command can return the properties that are implemented
on the termination. Similar to the statistics descriptor the property value
should be optional thus allowing MG to return only the list of properties
that are support on the termination. The grammar now has

propertyParm         = pkgdName parmValue

this needs to be modified to

propertyParm         = pkgdName [ parmValue ].

Best Regards.
Madhubabu

---

From: Willy Reheul <[email-masked]>
Date: Wed, 28 Feb 2001 14:58:58 +0100

Many thanks for the answers. For the time being, I'll forget everything
about (in my perception 'impossible') ServiceChanges and Audits on
ephemerals.
I do have however, a few remarks inline.

Willy.

> That's why you Audit after you establish a control association.
I'm learning something new here.
Sofar I thought that the ROOT termination represents the 'core' -ie
everything related to CONTROL- of the IMG and is not tied together with
any physical or ephemeral termination -ie everything related to
TRANSPORT of user traffic- inside the IMG. In other words the ROOT
termination can be perfectly working -hence can register with its MGC-
while in a worst case the physicals and/or ephemerals are not even
there.
I do run fast tests before generating the 'IMG-boot-success_event' which
then launches the registration scenario, but fast tests are limited to
tests inside the core of the IMG (processor tests, database tests, tests
of internal interfaces, buses, etc.....) and do neither cover the
ephemerals nor the physicals -although there may always be some
overlaps-.
Look at the following example : a trunkgateway has 1 out of 256 E1
boards failing/not equipped or has 1 out of 8000 E0's failing; would
this gateway refuse to register with its MGC because so-said "there is
no serviceCHANGE"?
I'm sure this MG does register with its MGC. MGs then start online test
and/or scheduled routine tests and/or permanent monitoring functions,
and/or event supervision, and many more.... related to their physical
and ephemeral equipment. The results of these may generate subsequent
serviceChange messages. The latters ones -of course- do not contain the
ROOT id but the involved physical or ephemeral  termination id.
Anyway, my understanding sofar, WAS that ROOT stands NEXT TO any one
physical and ephemeral termination.
My understanding WAS NOT that ROOT includes the physicals/ephemerals,
nor that ROOT ever could point to or say something about any one 
physical/ephemeral.
Must MGC then expect (maybe lots of) subsequent serviceChanges for the
physical terminations in order to set them inservice ?
It could have been the way of doing, but these transactions can be
avoided because it is common practice that parties (MG and MGC) involved
in registration ASSUME "inservice" state. As long MGC has got no
"outofservice' changes from the MG -immediately after registration or
anytime later during its present life- terminations are assumed to be
"inservice".
Must MGC audit an MG that registers with him ? No, MG will take all the
necessary initiatives to report outofservice terminations to MGC.
I hope I have the right view on these things.
> W-AuditCapability=bd1/*{Audit{media}}
Something puzzles me already for some time.
On the one hand the standard does not enforce the use of naming
conventions and therefor -whichever side of the interface one is- better
do not assume it.
On the other hand designers are often adviced to implement names; at
least this is the impression I got sofar from reading some threads in
this mailing list.
Why is that, do I miss something ?
What I mean is -suppose ephemerals have no termination id structure at
all, and have a dynamic numbering scheme that requires knowledge of
stream specific properties before any meaningful numbers can be assigned
to them - do you think IMG can insert some value in the parameter
TerminationID in the audit reply ?