Subject: RE: physical vs. ephemeral terminations

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 20 Feb 2001 10:19:18 -0500

I'd like to settle this issue, in favor of allowing AuditCapability
on wildcard response non-existing ephemerals.  If it's acceptable,
I'll draft wording for the Implementor's Guide.
 
I used an improper example of modifying ServiceState.
Chuong is correct.
 
Brian

-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: Tuesday, February 20, 2001 9:59 AM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: physical vs. ephemeral terminations

I agree w/Brian that you can do an AuditCapability on ephemeral. 
I don't think it is written anywhere that ephemeral termination has to exist
to be audited. 

A MG will know what is the range of ephemeral termination that it can
created since 
MGC can ask it to create ephemeral by doing an ADD w/choose. 
Thus MG already has to keep track of 
what ephemeral terminationId it had creates to prevent conflict in the name
as it is 
asked to ADD ephemeral term. 
So to stress this further, for AuditCapability on ephemeral (ALL), MG will
return all the range of 
ephemeral terminationIds that it can create and the capabilities of each
ephemeral terminations. 

Brian 
You have always advocated that a certain funtionality is best achieved by 1
command 
and not by 2 commands (like Move, Subtract and Add) 

Your comment below regarding using Modify to change the termination
ServiceState seems 
to contradict what you are advocating. 
I thought that this was discussed last year that only ServiceChange can
change 
the termination ServiceState. 
Also that the ServiceState in the TerminationState is a read only property. 
But I do see that this is not documented. 

Chuong 

"Rosen, Brian" wrote: 

You can respond to an AuditCapability.  The response to AuditCapability 
does not require that the ephemeral exist, because no state is required 
to determine the output.  The matching logic could quite reasonably 
determine 
that. 

Note that you actually can already do an "Add", although it creates 
a context in the process. 

Modify is interesting.  How do you mark an Ethernet interface out of 
service? 
If you have one, the flows might be RTP/*, ephemeral of course. 
Do you want to be able to say: 
  Modify=RTP/*{TerminationState{ServiceStates=OutOfService}} 

Brian 

> -----Original Message----- 
> From: Madhu Babu Brahmanapally [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, February 01, 2001 8:06 PM 
> To: 'Rosen, Brian'; [email-masked] 
> Subject: RE: physical vs. ephemeral terminations 
> 
> 
> Hi Brian,list, 
> How can MG/MGC responds on terminations that are not 
> existing. Ephemeral 
> terminations are created and destroyed by Add and Subtract commands. 
> Commands to Ephemeral terminations always should be addressed 
> with valid 
> Context Identifiers. I'm confused how MGC can Audit on 
> terminations that 
> doesn't exist (Irrespective of the naming schema)? Am I 
> missing anything 
> here!! 
> 
> Best Regards. 
> Madhubabu 
> 
> -----Original Message----- 
> From: Media Gateway Control (megaco) 
> [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of Rosen, Brian 
> Sent: Thursday, February 01, 2001 1:39 PM 
> To: [email-masked] 
> Subject: Re: physical vs. ephemeral terminations 
> 
> 
> y'know, I saw that discussion, and never said anything because 
> I never knew where the idea came from that you can't audit 
> a non-existent ephemeral.  I believed you could, precisely for 
> the reason we are discussing.  I'm glad you are as confused as 
> I.  Maybe we can claim you can in the absence of language to 
> the contrary in the spec. 
> 
> More specifically, I think that if you do: 
> Context=-{W-AuditCapabilities=foo/*{Audit{Packages}}}} 
> you should get a meaningful response. 
> 
> Brian 
> 
> > -----Original Message----- 
> > From: Tom Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > Sent: Thursday, February 01, 2001 12:31 PM 
> > To: [email-masked] 
> > Subject: Re: physical vs. ephemeral terminations 
> > 
> > 
> > In saying what I did about audits, I was quoted consensus 
> > doctrine (with 
> > which I do not personally agree) that you cannot audit 
> capabilities of 
> > terminations which have not yet been instantiated.  I just 
> > tried to find 
> > any mention of this restriction in H.248 and failed.  Brian, 
> > do you know 
> > where it is, or is my memory of the position incorrect? 
> > 
> > Troy Cauble wrote: 
> > > 
> > > > Tom-PT Taylor wrote: 
> > > > 
> > > > Hi. 
> > > > 
> > > > > -----Original Message----- 
> > > > > From: Troy Cauble [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > > > Sent: Wednesday, January 31, 2001 7:53 PM 
> > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] 
> > > > > Cc: [email-masked] 
> > > > > Subject: Re: physical vs. ephemeral terminations 
> > > > > 
> > > > > 
> > > > > 
> > > > > Tom Taylor wrote: 
> > > > > 
> > > > > > >What is the error returned if an MG is asked to do 
> something 
> > > > > > >it doesn't support (or doesn't even make sense) on 
> that type 
> > > > > > >of termination? 
> > > > > > >        If it's asked to detect hook flash on an ephemeral 
> > > > > > >        termination? 
> > > > > > 
> > > > > > [PTT] 
> > > > > > 440 Unsupported or unknown package 
> > > > > > 
> > > > > > >        If it's asked to apply Local or Remote Descriptors 
> > > > > > >        to a physical termination? 
> > > > > > 
> > > > > > [PTT] 
> > > > > > Not an error, though the I-D describing SDP naming 
> > > > > conventions (SDP nettype, addrtype) for TDM circuits has to 
> > > > > be written.  You 
> > > > > > need the descriptors to describe the codec (as Madhue has 
> > > > > pointed out) and the bearer capability. 
> > > > > 
> > > > > Tom, 
> > > > > 
> > > > > Well, it's an error for a POTS line.  What's the error 
> > code for that? 
> > > > > (Don't say 440; we're not talking about packages here.) 
> > > > 
> > > > [PTT] 
> > > > Even for an analogue line you need SDP saying that it is 
> > carrying an audio 
> > > > stream. 
> > > 
> > > Really?!  What does that SDP look like? 
> > > 
> > > I thought you identified the codec, etc. in the ephemeral RTP 
> > > termination and added that and the analogue line termination 
> > > to the same context, a la #12 in Appendix A. 
> > > 
> > > > > I guess you're saying that the schema doesn't have to 
> > > > > explicity distinguish between termination types, as 
> > > > > long as the MGC and MG both know the mapping.  Correct? 
> > > > > 
> > > > > So a schema could be simply integers 1-1000, and the MGC just 
> > > > > knows that the POTS line to my house is 37, while 36 
> > > > > and 38 are to be used for RTP streams? 
> > > > [PTT] 
> > > > Don't forget audits, at least for physical terminations. 
> > There is a missing 
> > > > link for ephemerals: they can't be named or audited until 
> > they exist.  I 
> > > > think the answer has to be in defining container 
> > terminations representing 
> > > > the physical interfaces, as I mentioned yesterday.  I 
> > think I'll have a go at 
> > > > the necessary package definition today. 
> > > 
> > > "can't be named until they exist" 
> > > 
> > > OK. Let's see if I've got this right... 
> > > 
> > > Physical terminations always "exist", they just move to and from 
> > > the null context. 
> > > Ephemeral terminations are created and destroyed. 
> > > 
> > > Does CHOOSE mean "choose among the existing" or "choose 
> > > among the entire schema".  I guess it means the latter 
> > > otherwise we couldn't create an ephemeral with Add/CHOOSE. 
> > > 
> > > So by "can't be named", do you mean by the MGC?  As in the 
> > > MGC can't say "Add termination RTP/8" for ephemerals even 
> > > though it knows the schema and knows that it's not in use 
> > > (doesn't "exist")? 
> > > So the MGC *MUST* use Add/CHOOSE for ephemerals? 
> > > 
> > > Thanks, 
> > > -troy 
> > 
>

-- 

  Alcatel USA, Inc             Internet: [email-masked]

  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613

  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Tue, 20 Feb 2001 11:09:16 -0500

It was discussed earlier in the list that the modification of the service
state should be allowed from MGC. But an typical MGC will not do that. As in
the Brian's mail lets document it so that we say whether modification of
state in any command other than "Service change" is legal or not.

Best Regards.
Madhubabu
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Rosen, Brian
  Sent: Tuesday, February 20, 2001 10:19 AM
  To: 'Chuong Nguyen'
  Cc: [email-masked]'
  Subject: RE: physical vs. ephemeral terminations

  Brian
    -----Original Message-----
    From: Chuong Nguyen [mailto:[email-masked]]
    Sent: Tuesday, February 20, 2001 9:59 AM
    To: Rosen, Brian
    Cc: [email-masked]
    Subject: Re: physical vs. ephemeral terminations

    I agree w/Brian that you can do an AuditCapability on ephemeral.
    I don't think it is written anywhere that ephemeral termination has to
exist to be audited.
    A MG will know what is the range of ephemeral termination that it can
created since
    MGC can ask it to create ephemeral by doing an ADD w/choose.
    Thus MG already has to keep track of
    what ephemeral terminationId it had creates to prevent conflict in the
name as it is
    asked to ADD ephemeral term.
    So to stress this further, for AuditCapability on ephemeral (ALL), MG
will return all the range of
    ephemeral terminationIds that it can create and the capabilities of each
ephemeral terminations.

    Brian
    You have always advocated that a certain funtionality is best achieved
by 1 command
    and not by 2 commands (like Move, Subtract and Add)

    Also that the ServiceState in the TerminationState is a read only
property.

    Chuong

    "Rosen, Brian" wrote:

      You can respond to an AuditCapability.  The response to
AuditCapability
      does not require that the ephemeral exist, because no state is
required
      to determine the output.  The matching logic could quite reasonably
      determine
      that.
      Note that you actually can already do an "Add", although it creates
      a context in the process.

      Brian

      > From: Madhu Babu Brahmanapally [mailto:[email-masked]]
      > [mailto:[email-masked]]On Behalf Of Rosen,
Brian
      > > From: Tom Taylor [mailto:[email-masked]]
      > > > > > From: Troy Cauble [mailto:[email-masked]]

---

From: "Michael Brown" <[email-masked]>
Date: Tue, 20 Feb 2001 13:02:35 -0500

I would agree with the statements about allowing (or describing) use of
AuditCapability with a wildcard to request information about nonexistent
ephemerals.

I disagree however about the proposed limitation on using only
ServiceChange to modify terminationstate. This would mean that there
would be no way to set the terminationstate to TEST. I don't think that
the use of MODIFY to set terminationstate should be made illegal.

Michael

Madhu Babu Brahmanapally wrote:

>  It was discussed earlier in the list that the modification of the
> service state should be allowed from MGC. But an typical MGC will not
> do that. As in the Brian's mail lets document it so that we say
> whether modification of state in any command other than "Service
> change" is legal or not.Best Regards.Madhubabu
>
>      I'd like to settle this issue, in favor of allowing
>      AuditCapabilityon wildcard response non-existing
>      ephemerals.  If it's acceptable,I'll draft wording for the
>      Implementor's Guide.I used an improper example of modifying
>      ServiceState.Chuong is correct.Brian
>
>           I don't think it is written anywhere that
>           ephemeral termination has to exist to be audited.
>
>           A MG will know what is the range of ephemeral
>           termination that it can created since
>           what ephemeral terminationId it had creates to
>           prevent conflict in the name as it is
>           So to stress this further, for AuditCapability on
>           ephemeral (ALL), MG will return all the range of
>           ephemeral terminationIds that it can create and
>           the capabilities of each ephemeral terminations.
>
>           Brian
>           You have always advocated that a certain
>           funtionality is best achieved by 1 command
>           Your comment below regarding using Modify to
>           change the termination ServiceState seems
>           I thought that this was discussed last year that
>           only ServiceChange can change
>          > > [mailto:[email-masked]]On
>          > Behalf Of Rosen, Brian

---

From: Chuong Nguyen <[email-masked]>
Date: Tue, 20 Feb 2001 13:13:47 -0600

Wanting to use Modify to change ServiceState to TEST sounds reasonable.

But let's go over what this "TEST" state is for.

First one would use ADD to add a termination to a context.
To use a termination for traffic the ServiceState has to be in-service.
But I also want to perform COT right after the add the termination.

So do I have to specify ServiceState to be TEST in the ADD?
Or do I have to send a Modify to MG w/ServiceState set to TEST before
telling it to
perform COT?
After COT, does MGC has to send a Modify to change the ServiceState back
to
in-service to continue the call.
Now you got a few more extra messages going back and forth just to set
up a call.

I think Tom argued that COT is not the kind of "TEST" that he had in
mind.
So what kind of testing is "TEST" supposed to indicate?

I think there was the argument that an MG operator might want to perform
some line testing
on certain terminations.
But how can MG notify that the ServiceState is test when Modify only
goes from MGC to MG?
ServiceChange does not have a "TEST" method.
So the MG operator takes the terminations out-of-service to perform
whatever test he wants
on the terminations.
So now one has a situation where OOS is being used for "TEST".

Now MGC might want to use TEST to tell MG that a termination is being
used for testing.
Therefore one would normally expect the termination is not used for
traffic.
The definition for OOS is   "indicates that the termination cannot be
used for traffic".
So the question is - Do TEST and OOS both indicate that the termination
cannot be used
for traffic?  So do we really both TEST and OOS?

Another question is, if one uses ADD to add a termination to a context
w/ServiceState sets
to TEST and performs some testings.
After testing, one does a SUBTRACT.  Does one still get statistics?

Said one use MODIFY to set a termination ServiceState in the NULL
context to TEST
and performs some testing, how does one get the statistics?
AuditValue.   But how does one clear the statistics?

So after rambling on, I hope everyone sees that it could get complicated
real quick.
I think any changes need to provide something that clearly covers all
possible scenarios.
Otherwise we will be visiting the same issue over and over.
Or just try to make everything as simple or not so flexible in the first
round to simplify
the implementaiton.

Chuong

Michael Brown wrote:

> I would agree with the statements about allowing (or describing) use
> of AuditCapability with a wildcard to request information about
> nonexistent ephemerals.
>
> would be no way to set the terminationstate to TEST. I don't think
> that the use of MODIFY to set terminationstate should be made illegal.
>
> Michael
>
>> service state should be allowed from MGC. But an typical MGC will
>> not do that. As in the Brian's mail lets document it so that we say
>>      Implementor's Guide.I used an improper example of
>>      modifying ServiceState.Chuong is correct.Brian
>>
>>           So to stress this further, for AuditCapability
>>           on ephemeral (ALL), MG will return all the range
>>           of
>>           Also that the ServiceState in the
>>           TerminationState is a read only property.

---

From: Willy Reheul <[email-masked]>
Date: Wed, 21 Feb 2001 19:25:17 +0100

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: Wed, 21 Feb 2001 15:09:53 -0500

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

thanks,
Willy.

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 21 Feb 2001 16:27:08 -0500

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

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Wed, 21 Feb 2001 20:37:46 -0500

hi Kevin,
This goes on similar lines like auditing the ephemerals(whether they are
created or not). The Error code 510 "insufficient resources" is very
abstract to address cases like board going out,etc.
Best Regards.
Madhubabu

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 21 Feb 2001 21:42:58 -0500

This is all fine, except now you are forcing the MGC to keep track of ephemeral
terminations too, which is a significant change from the way the spec is
drafted.  Ephemerals are created and destroyed on the fly.  How can you perform
a ServiceChange on something that doesn't exist? What, exactly are you taking
out of service?  Further, why does the MGC need to know whether an ephemeral is
out of service?  The MG is in control of what ephemerals are/aren't used at any
given time... the MGC has no power over this.  When the MGC asks for a new
ephemeral, the MG assigns it according to its own internal devisings.  Further,
the MG has NO limitations as to naming convention... the MG could name its
ephemerals John, Paul, George and Ringo for all the spec cares.  And whether you
support naming conventions or not, because the spec doesn't enforce it, you
can't assume it.  So, potentially, if a pool goes out, now you get a zillion
ServiceChanges on individual ephemerals that the MGC has no knowledge of.  So,
you are left with a bunch of ServiceChange messaging that means absolutely
nothing to the MGC.

Audits and ServiceChanges are two VERY different operations.  I can see the
utility in Auditing ephemerals, to determine capability levels about the gateway
with regard to packet streams.  Allowing ServiceChanges makes ephemerals into
discreet resources like physicals, instead of the pooled resource which they are
now.  Further, this change is going to force a lot of knowledge into the MGC
that it doesn't have at this time.  If you're going to allow ServiceChanges on
ephemerals, then why not have the MGC direct the use of them like it does with
physicals.  I really believe that this is a fundamental operational change in
the protocol, and should wait until v2.

And, if you think the error codes are too vague, then feed some input into Annex
L and get some new ones created!

Kevin

---

From: "Michael Brown" <[email-masked]>
Date: Thu, 22 Feb 2001 17:59:35 -0500

Given the direction that the original thread has taken, I thought this 
should be split out as a separate thread.

Since your post had a number of  questions throughout, I have added 
comments inline.

Chuong Nguyen wrote:

> After COT, does MGC has to send a Modify to change the ServiceState 
> back to
The TEST state is one in which the MGC or some other maintanence system 
could request certain diagnostic functions be performed such as a 
Metallic Test Access. The TEST state doesn't relate to COT as performed 
during call processing. There is COT type testing which can be used as a 
diagnostic test function which is an appropriate behavior when in the 
TEST state.

> I think there was the argument that an MG operator might want to 
> perform some line testing
> on certain terminations.
Actually, in this scenario, I don't believe that the MG DOES have to 
inform the MGC of being set in the TEST state. One clarification is that 
there are both IS and OOS testing functions. The TEST state should be 
thought of as having the substates of IS and OOS. The behavior would be 
that whatever state the line is in at the time of requesting the TEST 
state would be retained as a substate of TEST. A maintenance system 
might request (outside the scope of Megaco) to perform testing. If OOS 
testing was desired, the termination would need to be placed in that 
state prior to invoking the TEST state. The MGC would be made aware of 
the change to OOS, but since it didn't request the TEST state it would 
be oblivious to the TEST functions/results. If the termination is IS and 
the maintenance system requested the TEST state, again the MGC could be 
oblivious of it since from the MGCs perspective the termination is IS 
and would operate on it as such.

> traffic
This is the other possible scenario. In this case, the same behavior 
applies that the state of the termination is treated as a substate of 
TEST. The difference is that both the MG AND the MGC are aware of the 
TEST state.

> So the question is - Do TEST and OOS both indicate that the 
> termination cannot be used
Yes, we do need both. As described above, there really needs to be the 
ability to perform both IS testing or OOS testing.

> After testing, one does a SUBTRACT.  Does one still get statistics?
Yes, but see below.

> AuditValue.   But how does one clear the statistics?
The quick answer is that the test results will not be conveyed as 
statistics but instead will be captured and queried as properties. I 
hate to defer on answering this question more completely at this time, 
but I think it will become clear once we have published our draft on the 
Metallic Test Access package.

> 
>  
> 
> So after rambling on, I hope everyone sees that it could get 
> complicated real quick.
> Or just try to make everything as simple or not so flexible in the 
> first round to simplify
> the implementaiton.
> 
I do agree that there needs to be additional clarification of the use of 
the TEST state. My plan has been to propose some text for the 
Implementor's Guide once we published the proposal for an MTA package. 
That will be coming very soon.

I would reiterate that the bottom line of my initial response was that I 
don't want the limitation placed on terminationstate to be controlled 
only by ServiceChange.

Michael

>>>     AuditCapabilityon wildcard response non-existing ephemerals.  If 
>>>     it's acceptable,I'll draft wording for the Implementor's Guide.I 
>>>     used an improper example of modifying ServiceState.Chuong is 
>>>     correct.Brian
>>>     
>>>         I don't think it is written anywhere that ephemeral 
>>>         termination has to exist to be audited.
>>>         
>>>         A MG will know what is the range of ephemeral termination 
>>>         that it can created since
>>>         what ephemeral terminationId it had creates to prevent 
>>>         conflict in the name as it is
>>>         So to stress this further, for AuditCapability on ephemeral 
>>>         (ALL), MG will return all the range of
>>>         ephemeral terminationIds that it can create and the 
>>>         capabilities of each ephemeral terminations.
>>>         
>>>         Brian
>>>         You have always advocated that a certain funtionality is 
>>>         best achieved by 1 command
>>>         Your comment below regarding using Modify to change the 
>>>         termination ServiceState seems
>>>         I thought that this was discussed last year that only 
>>>         ServiceChange can change
>>>>          > [mailto:[email-masked]]On Behalf Of 
>>>>         Rosen, Brian