Subject: RE: physical vs. ephemeral terminations

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 20 Feb 2001 11:15:16 -0500

The MGC can do it with ServiceChange.  The question is can anyone modify
the bit in the TerminationState descriptor.  I believe that the answer is
no.
 
Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: Tuesday, February 20, 2001 11:09 AM
To: 'Rosen, Brian'; [email-masked]
Subject: RE: physical vs. ephemeral terminations

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

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:26:42 -0500

hi all,
Where can one find the new mail archives for the Megaco. The mail archive on
standards.nortelnetworks.com is closed since Feb13.
Best Regards.
Madhubabu