Subject: RE: physical vs. ephemeral terminations

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 26 Feb 2001 05:50:52 -0500

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: Willy Reheul <[email-masked]>
Date: Tue, 27 Feb 2001 15:45:24 +0100

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.)
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.
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. 

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 ?

/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.)

/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.

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 ?

/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.
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 ? 
-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 ?
-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".
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-.

/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 ?
By the way, when and why exactly does one chooses for the physical or
the ephemeral model? Everything is physical after all.

/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.

Thanks,
Willy

> Tom-PT Taylor wrote:
> terminations going out of service.  What context would the action
> containing the ServiceChange for a group of terminations show?
>