Subject: Packages Supported By A Termination

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 11 Jan 2000 10:01:08 -0600

It has occurred to me that the means by which a termination becomes
associated with a set of packages is quite obscure and generally indirect.
For instance, support of specific bearer-type-related packages will be
inferred from the nettype and addrtype used in session descriptions within
the Local and Remote descriptors.  Support of a DTMF package will be
inferred from the use of DTMF events or signals in the respective
descriptors.

Is this how people see the relationship between packages and terminations in
general, or do we need a more specific method of specifying support, such as
a package list in TerminationState?  (Note that Package Descriptor is
returned from audits, but cannot be set.)

Tom Taylor
Advisor -- IPConnect Standards
E-mail: [email-masked] (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jan 2000 11:08:07 -0500

I don't understand this.

The packages realized by a termination is fixed, mostly at
design time, possibly altered by provisioning.  There isn't
anything you can "set".  Auditing to find out what packages
are implemented is there.  It's the "package list" you
asked for.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Tuesday, January 11, 2000 11:01 AM
> To: [email-masked]
> Subject: Packages Supported By A Termination
>
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 11 Jan 2000 11:18:16 -0500

If the MGC orders up an ephemeral termination, the stack (whether ATM or IP
based) supported by that termination is determined by the session
descriptions in Local and Remote -- it's not pre-provisioned.

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Tuesday, January 11, 2000 11:08 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
> Subject:      RE: Packages Supported By A Termination
>
> I don't understand this.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jan 2000 13:37:48 -0500

We have not determined if there is a package associated with
ATM (or IP), and what it needs to have in it.  Right at the
moment, unless the package defines extensions to Annex C and
SDP, I don't think it has any purpose.

If there are such packages, then the audit of packages tells
you that you can order up a bearer of that type.

We have not discussed what audit of local does, but presumably it
gives you what the MG could accept as SDP/Annex C.  In that case
such an audit would tell you what types of ephemerals you
can ask for.

We certainly don't need anything else.

Brian

> Sent: Tuesday, January 11, 2000 11:18 AM
> Subject: Re: Packages Supported By A Termination
>
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 11 Jan 2000 12:58:02 -0600

Basically you need at least three items in an ATM package that I can think
of off the top of my head: the nettype and addrtype extensions to SDP, means
to specify all the ATM-related parameters (darned if I know how -- SDP
attributes generally seem to be associated with codecs, not bearers), and
ATM-specific statistics.  I can't think of any need for an IP package at
this point -- we would collect statistics at a higher level (RTP, whatever
is inherent in an alternative encapsulation), and SDP doesn't need extending
to handle it.  We do need to extend SDP to handle TCP transport.

It's all very well to say that the MG will support ephemeral terminations
with this package or that package, but once an ephemeral has been
instantiated, how will an audit determine the contents of the package list
for that specific termination?  I believe it will do it as I say, by
inferring it from the termination's current properties.

> Sent: Tuesday, January 11, 2000 1:38 PM

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 11 Jan 2000 13:39:45 -0600

The original Annex C most assuredly has RTP and ATM things in it.  Yes, it's
the SDP that gets extended when we're talking text encoding.

We're really in a black hole if we can't extend SDP through our
documentation -- we have to have documentary support to register the stuff
with IANA per the SDP RFC.  I haven't managed to get together with Joerg Ott
to figure out how or whether MMUSIC could do it for us instead.

My musings about packages have to do with implementation rather than the
protocol itself.  The protocol provides the means to express the fact that a
certain termination supports certain packages, but the question was how an
MG implementor figured out what to put in that list.

> Sent: Tuesday, January 11, 2000 2:09 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
> Statistics, that's a good reason.  Let's decide - we will have RTP and ATM
> packages
> they will have at least statistics in them.  An audit would tell you that
> you can create
> the appropriate ephemeral.
>
> The question remains, does a package get to define extensions to SDP and
> Annex C?
> Does the original Annex C have ATM and RTP things in it?  Does the
> original
> document have any SDP extensions for ATM?  NetType is found in both Annex
> C
> and SDP.  In SDP we need to have the specifics, but the place to put it is
> in the SDP,
> and not in LocalControl, right?  Same with addrtype.  So if a package
> could define
> extensions to Annex C and SDP, then you could define the ATM extensions to
> SDP in the ATM package.  I'm not sure we want to allow such a thing.
>
> I'm still mystified what problem you see auditing.  If you have an
> ephemeral,
> an audit will tell you what packages it implements.
>     AuditValue=RTPxxxxx{Audit{Packages}}
> returns the list of packages implemented on the ephemeral RTPxxxxx
>
> Brian.
>
>       Sent: Tuesday, January 11, 2000 1:58 PM
>       To: Rosen, Brian; [email-masked]
>       Basically you need at least three items in an ATM package that I can
> think of off the top of my head: the nettype and addrtype extensions to
> SDP, means to specify all the ATM-related parameters (darned if I know how
> -- SDP attributes generally seem to be associated with codecs, not
> bearers), and ATM-specific statistics.  I can't think of any need for an
> IP package at this point -- we would collect statistics at a higher level
> (RTP, whatever is inherent in an alternative encapsulation), and SDP
> doesn't need extending to handle it.  We do need to extend SDP to handle
> TCP transport.
>
>       It's all very well to say that the MG will support ephemeral
> terminations with this package or that package, but once an ephemeral has
> been instantiated, how will an audit determine the contents of the package
> list for that specific termination?  I believe it will do it as I say, by
>       > From: Tom-PT Taylor [ <mailto:[email-masked]>]
>       > > > From: Tom-PT Taylor [ <mailto:[email-masked]>]