Subject: Re: Choosing of ephemeral / physical Termination.

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 10 Feb 2000 09:15:19 -0500

> In the example  given, the termination Id look like
>           MyDS3/3/5  which follows the schema by MG
> TrunkGroup/Trunk/Circuit
>
> The fundamental question is, how does the MGC will understand
> this schema?
> For example if MGC wants to select all the circuits in MyDS3
> and Trunk 3, it
> would use the termination id MyDS3/3/* if MGC can understand
> the schema used by MG.
Look at either of the two most recent versions for the "Name Pattern"
properties in the root package.  This provides a way
for the MGC to discover the name scheme in the MG.  Alternatively,
this information can be provisioned in the MGC.

> In the event MGC doesn't know the schema used by MG, then
> schema TrunkGroup/Trunk/Circuit
> doesn't convey much information. Then, the Termination Id is
> mere a string and doesn't convey
> any message to MGC.
In some way or other, the MGC must know how to specifically
address each of the circuits in the MG.  It could only understand
a string name for an end circuit.  For some MGCs, that may be
sufficient.  The naming schema is usefull for:
        Allowing the MG to select a circuit using CHOOSE
        Allowing the MGC to do efficient Auditing, while
                controlling the amount of data sent from one audit
The later is what drove the "Name Pattern" properties mechanism.

Brian
> Please clarify with respect to the example.
>
> Thanks,
> Singar/..
>
>
>
> On Tue, 1 Feb 2000 10:59:53 +0100, Christian Groves
> <[email-masked]> wrote:
>
> >G'Day Brian,
> >
> >Sounds like you're leading me somewhere ;-). In answer to
> your questions
> >I believe you could ask for what you've specified below.
> Whether that's
> >the best way to do it is another question.
> >
> >Cheers, Christian
> >
> >"Rosen, Brian" wrote:
> >>
> >> Just checking my assumptions:
> >>         For a physical termination, you want to be able to say:
> >>                 MyDS3/3/$
> >>        meaning, you choose any DS0 you want in the 3rd DS1
> of a DS3,
> >> assuming that
> >>          was how my MG named the DS0s (such a structure
> NOT being required).
> >> Could
> >>         I also ask for MyDS3/$/$?
> >>
> >>         For an ephemeral termination, suppose that I knew,
> by discovery or
> >>         provisioning that RTP bearers were named RTP/nnnn
> and ATM bearers
> >> were
> >>         named AAL1/nnnn/nn.  Can I Add=AAL1/0003/$, which
> means create an
> >>         ephemeral for an ATM AAL1 bearer, with the MG choosing the
> >> subchannel?
> >>
> >> Brian
> >>
> >> > -----Original Message-----
> >> > From: Christian Groves [mailto:[email-masked]]
> >> > Sent: Monday, January 31, 2000 10:27 AM
> >> > To: [email-masked]
> >> > Subject: Re: Choosing of ephemeral / physical Termination.
> >> >
> >> >
> >> > Hello all,
> >> >
> >> > I believe that we have diverged from the first email in this
> >> > thread. We
> >> > do not need rules to determine what media and bearer is
> instantiated.
> >> >
> >> > For a physical termination a certain terminationID schema will be
> >> > assigned by the MG. ie. /myscheme/physical/trunk/circuit
> >> > If the MGC wanted to CHOOSE a physical termination it
> could either
> >> > wildcard 'trunk' or 'circuit'.
> >> >
> >> > For a emphemeral terminatoion a certain terminationID
> schema will be
> >> > assigned by the MG. The MGC by various means would be
> aware of this
> >> > scheme.
> >> > ie. /myscheme/euphemeral/IP
> >> > If the MGC wanted to CHOOSE a euphemeral termination it
> could wilcard
> >> > the 'IP'
> >> >
> >> > The 'physical' and 'ephemeral' could be anything in the the
> >> > MG assigned
> >> > scheme that would differentiate the two.
> >> >
> >> > If the MGC doesn't care which one then it CHOOSES on the
> >> > 'ephemeral'/'physical' level. The MG can determine which
> one to return
> >> > from ANY information in the media descriptors. This is
> >> > something for the
> >> > MG to decide, not something that needs to be specified in
> >> > rules in H248
> >> > because they'll probably change according to your
> >> > application, resource
> >> > allocation algorithms in the MG, etc. I do agree that an
> >> > error should be
> >> > returned if the MG cannot determine the terminationID.
> >> >
> >> > I think the scope of this is also limited to the ADD
> command. The ADD
> >> > will return a fully specified terminationID which can then be
> >> > referenced
> >> > in Move, Modify, Subtract etc.
> >> >
> >> > Regards, Christian
> >> >
> >> > Tom-PT Taylor wrote:
> >> > >
> >> > > Right, we haven't converged yet.  I have a suggestion which may
> >> > > resolve this, that we add these rules
> >> > >
> >> > > (1) If the MGC provides too little information in an
> Add command for
> >> > > the MG to select the bearer type for that termination,
> the MG must
> >> > > reject the command with [appropriate error].  In practice,
> >> > this means
> >> > > either that the terminationID in the command provides
> the necessary
> >> > > information, or else that at least one instance of a
> Local or Remote
> >> > > descriptor must be present, containing a c= line with
> a specified
> >> > > nettype (or the Annex C equivalent).
> >> > >
> >> > > (2) If the MGC provides too little information in an
> Add, Move, or
> >> > > Modify command for the MG to determine the medium to
> be carried in a
> >> > > given stream, the MG must reject the command with [appropriate
> >> > > error].  The MG has three ways to determine medium:
> >> > >
> >> > >  - streamID unspecified defaults to streamID=1 and medium=audio
> >> > >  - medium has already been specified for that streamID
> for another
> >> > > termination in the same context
> >> > >  - explicit specification of medium in an m= line (or
> the Annex C
> >> > > equivalent) in an instance of Local or Remote for the given
> >> > streamID.
> >> > >
> >> > >      -----Original Message-----
> >> > >      From:   Rosen, Brian [SMTP:[email-masked]]
> >> > >      Sent:   Monday, January 31, 2000 9:15 AM
> >> > >      To:     [email-masked]
> >> > >      Subject:        Re: Choosing of ephemeral / physical
> >> > Termination.
> >> > >
> >> > >      I believe we have not reached consensus on this
> issue, so I did
> >> > >      not
> >> > >      change the text.  Tom, is that your view?
> >> > >
> >> > >      Brian
> >> > >
> >> > >      > -----Original Message-----
> >> > >      > From: Sachin Mittal [mailto:[email-masked]]
> >> > >      > Sent: Monday, January 31, 2000 2:52 AM
> >> > >      > To: [email-masked]
> >> > >      > Subject: Re: Choosing of ephemeral / physical
> Termination.
> >> > >      >
> >> > >      >
> >> > >      > The point that "$" is for choosing ephemeral is
> not yet added
> >> > >      > in V14. Is it that
> >> > >      > the discussion
> >> > >      > is not yet complete? What about foo$ representing choose
> >> > >      physical.
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      > Sachin Mittal <[email-masked]> on 01/27/2000
> 11:35:50 AM
> >> > >      >
> >> > >      > Please respond to [email-masked]
> >> > >      >
> >> > >      > To:   [email-masked]
> >> > >      > cc:    (bcc: Sachin Mittal/HSS)
> >> > >      >
> >> > >      > Subject:  Re: Choosing of ephemeral / physical
> Termination.
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      > Its true that the type of termination should not be
> >> > >      > identified by looking into
> >> > >      > the descriptor
> >> > >      > information. Somewhere in the text this should
> be added that
> >> > >      > " $ if it appears
> >> > >      > alone indicates
> >> > >      > ephemeral termination and partial $ (ex foo$) indicates
> >> > >      > selection of a physical
> >> > >      > termination
> >> > >      > (a circuit within a trunk group)".
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      > "Rosen, Brian" <[email-masked]> on 01/27/2000
> 02:36:46 AM
> >> > >      >
> >> > >      > Please respond to "Rosen, Brian" <[email-masked]>
> >> > >      >
> >> > >      > To:   [email-masked]
> >> > >      > cc:    (bcc: Sachin Mittal/HSS)
> >> > >      >
> >> > >      > Subject:  Re: Choosing of ephemeral / physical
> Termination.
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      > Generally determined by the "kind" of
> termination requested.
> >> > >      > Which is in turn, easily discernable from the
> Media command.
> >> > >      >
> >> > >      > However, upon reflection, I think it's not a
> good answer.
> >> > >      > I'd propose that we not allow selection of a physical
> >> > >      termination,
> >> > >      > in which case choose is always create an ephemeral.  In
> >> > >      particular,
> >> > >      > the following is perfectly legal:
> >> > >      > Context=${Add=${}}
> >> > >      > What do you get?
> >> > >      >
> >> > >      > Brian
> >> > >      >
> >> > >      > > -----Original Message-----
> >> > >      > > From: Sachin Mittal [mailto:[email-masked]]
> >> > >      > > Sent: Tuesday, January 25, 2000 9:01 AM
> >> > >      > > To: [email-masked]
> >> > >      > > Subject: Choosing of ephemeral / physical Termination.
> >> > >      > >
> >> > >      > >
> >> > >      > > Annex B.1 says that "The CHOOSE TerminationID
> $ may be used
> >> > >      > > to signal to the MG
> >> > >      > > that it has to create an
> >> > >      > > ephemeral Termination or select an idle physical
> >> > >      Termination".
> >> > >      > > How can MG determine when to create an ephemeral
> >> > termination
> >> > >      > > and when to choose
> >> > >      > > idle physical termination.??
> >> > >      > > What is the logic behind this decision making?
> >> > >      > >
> >> > >      > > regards
> >> > >      > > -Sachin Mittal
> >> > >      > >
> >> > >      >
> >> >
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 10 Feb 2000 19:22:49 +0100

Hello all,

The addition of the "Naming pattern" in the Package was a mistake by the
 Editor (TD-33). It was highlighted in the word document for removal.
It should be removed as per TD-32 which was input to the ITU SG16
meeting.
It needs further CS2 development.

Cheers, Christian