Subject: Re: Choosing of ephemeral / physical Termination.

From: Sachin Mittal <[email-masked]>
Date: Tue, 1 Feb 2000 11:51:39 +0530

Quote...
> 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.
End quoted text.....

Is it provisioned ??
Can't we extend the pattern property recently defined in base root package.
If we do then we need to also specify the patterntype (ephemeral/physical)
property.

Sachin Mittal <[email-masked]> on 02/01/2000 09:34:31 AM

Please respond to [email-masked]

To:   [email-masked]
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Choosing of ephemeral / physical Termination.

Christian,
if MGC is aware of patterns of such kind, then
the issues/assumptions are as mentioned by Brian
But the original point was the the appearance
of $ with NO PRE-STRING and POST-STRING attached to it.
In that case how can you figure out what to choose.
I am not in favor of looking at media descriptor, etc
because they may not appear with the ADD.
Can we say ADD is successful if there doesn't yet
exist a "star connection" in the context in which atleast
one other termination is present ???

"Rosen, Brian" <[email-masked]> on 02/01/2000 01:09:49 AM

Please respond to "Rosen, Brian" <[email-masked]>

To:   [email-masked]
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Choosing of ephemeral / physical Termination.

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: Tue, 1 Feb 2000 10:59:53 +0100

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

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 1 Feb 2000 10:04:42 -0500

I'd like to make sure we agree on one point: IF a media descriptor is
present in an Add command, it must be honoured, not ignored.

Your concern, I believe, is that someone could issue the command
Context=${Add=${}} (Brian's example).  There are two ways of approaching the
issue: from what I would call a data processing point of view, and from a
physical point of view.

From the data processing point of view, the command shown above is always
valid.  At a minimum, it has the effect of causing the MG to allocate the
following:
 - a context identifier
 - a termination identifier
 - any software resources (place-holders for more information) the
implementation associates with these two entities.
Clearly this is not enough to support any flow of media, but until Mode is
set for some stream, this doesn't matter.

The physical view of the protocol would be that commands are only valid when
they provide information the MG can act on to allocate real resources.  It
was the physical view I was suggesting when I stated rules the other day
which would require that the bearer type be somehow inferrable, otherwise an
Add command fails.

Personally, I think the physical view will require us to make a series of
distinctions between valid and invalid command contents.  I favour the data
processing view simply because it will involve less work.  Other views may
differ.

> From: Sachin Mittal [SMTP:[email-masked]]
> Sent: Monday, January 31, 2000 11:05 PM

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 1 Feb 2000 17:54:18 -0500

> If we do then we need to also specify the patterntype

You don't need to do this.  Once you have a pattern, you can Audit Packages
to find out what the set of terminations can do.  You will get RTP, AAL1,
etc.
which tells you that it is an ephemeral, and what network type it is.

Brian

---

From: Singaraselvan Singaravelan <[email-masked]>
Date: Wed, 9 Feb 2000 19:38:15 -0500

Brian,

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.

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.

Please clarify with respect to the example.

Thanks,
Singar/..

---

From: Singaraselvan Singaravelan <[email-masked]>
Date: Thu, 10 Feb 2000 15:16:39 -0500

Hello all,

The explanation given by Brian does not clarify the doubts raised.
Let me repost the questions:

1. Do we still have the "Naming Pattern" in the Base Root Package ?
    From Christian's explanation, it will be removed (???)

2. MG is allowed to choose an arbitrary schema for naming Termination Ids
    Assume, the MG, uses the following schema to name the Termination Ids.
                TDM/OPC/DPC/CIC
    How does the MGC will know, second field in the Termination ID is OPC,
    3rd is DPC and 4th is CIC ?

    If MGC is intelligent enough to identify the 2nd field is OPC, 3rd is DPC and 4th CIC,
    then it would be easy to implement, CHOOSE, RANGE, LIST or ALL options.

   For example, TDM/300/400/5  => Circuit 5 with OPC = 300 & DPC = 400
                         TDM/300/400/*  => All Circuits with OPC = 300 & DPC = 400

3. Do we need to package which explains how the termination are named?
    So in a multi vendor, Media Gateway and MGC, if the package is supported
    we can easily maintain, universal naming of Termination Ids.

    Please clarify it with an example. It will avoid further clarifications.

    Thanks,
    Singar/..

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

>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
>
>"Rosen, Brian" wrote:
>>
>> 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 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