Subject: Re: Packages Conference Call Minutes

From: [email-masked]
Date: Thu, 7 Oct 1999 13:59:08 +0530

Brian,
               I have a small query embedded below preceded with <VB>.

Regards,

Vikas Bajaj

Brian Rosen <[email-masked]> on 10/07/99 04:29:10 AM

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

To:   [email-masked]
cc:    (bcc: Vikas Bajaj/HSS)

Subject:  Re: Packages Conference Call Minutes

> [CHG] I would guess that as part of a package registration
> process for a
> package that comes from a standards body is that it could
> have a certain
> prefix ie. ITU, ETSI, TIA etc and that when a Package name is
> registered
> it then has to point to a certain Technical recommendation or name.
Package names are used whenever you reference a package item.
Names should be short.
There is no need to have the defining body in the name.  If an MG
chooses to implement a package, it is just as legitimate if the
package definition was from Joe's Fine Packages Dot Com, or from ITU.
When it is registered, it must have a publicly available defining
document for sure.

>
> [CHG] Can you please clarify the agreement? I can see that when you
> implement a PAckage that you should implement all the properties but
> should you have to implement all the values of the property in the
> package. The example given was codec properties. I'm not sure that we
> agreed.
This is the nut of the problem.

If you don't implement all of the package, including all of the values,
what is the point of the package? - you can audit to find out what
the MG implements.  If you don't implement the whole thing then we don't
want packages, we want individual item definitions; grouping them is not
helpful.

The point of a package is if you implement it, you implement it all,
and then just looking at the package audit tells you what the MG does.

<VB> This is fine. My concern is that in such a case there may be a requirement
     to have some events/signals duplicated across packages. For example, there
     may be certain tones that may be required to be sent over a trunk as well
     as a line. In that case either these tones appear both in the Line and
Trunk
     packages or there is the requirement of a separate package that contains
     only tones. How will this issue be addressed ?

>
> [CHG] Does the latest ABNF support terminatinMode = send, receive,
> send/rec ?? It seems to be missing and should be added.
It's called "StreamMode" and is found in localControl.  It is in the
ABNF.  Mode is stream sensitive.

Brian

---

From: [email-masked]
Date: Thu, 7 Oct 1999 12:33:57 +0530

Al,
              I agree with your proposal that the Packages should be designed
such that they hide some of the "PSTN
  interface" details from the MGC. The abstraction of all PSTN analog signaling
  events/signals can be done keeping in view what is significant to the MGC from
  the Call Control perspective. Every thing that happens on the line need not be
  reported because it may be insignificant to the MGC.

Regards,

Vikas Bajaj
Gateway Development Team
Hughes Software Systems Ltd.

Al Varney <[email-masked]> on 10/07/99 02:54:17 AM

Please respond to Al Varney <[email-masked]>

At 12:22 10/06/1999 -0400, Chip Sharp wrote:
>In writing up an applicability statement for supporting T1 RBS with megaco,
>I had some similar questions to ones that came up on conference call.

>Related to these packages are packages for Loop Start/Ground Start
>(FXO/FXS) and E&M (there is a MF package somwhere) signaling.
>
>I would assume that an FX package could use the analogue line supervision
>package since FX is a direct analogue of analogue line supervision.
>
>An E&M supervision package would have special items like a wink, reverse
>wink, delay-dial, start-stop and other events and signals.

   This is a problem of determining the right level of abstraction.  One
could define a Robbed-Bit-Signaling Package, with Events/Signals equal
to each possible AB pattern (ABone, ABtwo, etc.).  Also works for ABCD
patterns for ESF and GR-303 control signaling.  This would work with any
Robbed-Bit DS1 interface.  No new package needed when someone introduces
a new D4 plug-in type.  In this case, the MG doesn't know if an interface
is FX or E/M or Coin or...  But I think that packaging is too primitive.
But The MG can be smarter (And we eliminate some timing issues.)

   At another level, one could argue that the package Events/Signals should
mirror an abstraction of the (mostly analog) PSTN protocols we wish to
support.
In that case, the MGC doesn't know or care if the interface happens to be
a REAL analog trunk, or the RBS-signaled equivalent.  We can operate in
the language of the PSTN protocol (off-hook, wink, ringback[ugh], reverse
polarity, etc.  In that case, loop start and ground start lines use exactly
the same events/signals -- some initial command from the MGC tells the MG
the "variation" to be used.  Same for RBS-emulated lines or DLC-controlled
lines.  Thus an MGC only knows about "lines", and has a many, many fewer
interaction cases to be developed/tested.

   Neither of these levels are necessarily "correct".  But I think one
should design packages that remove some of the "PSTN interface" details
from the MGC.  One really does want to say "send a WINK", rather than
"send an on-hook that persists for exactly N milli-seconds, then an off-hook,
unless you see an incoming on-hook while you are on-hook, in which case you
should NOT send an off-hook, but ignore incoming on-hooks that are shorter
than 50 milli-seconds.".

---------
>A question in this case is if the termination Mode is ReceiveOnly and it
>receives an inband tone for which it has an outstanding Event (e.g.,
>digits), does it pass that tone to the other terminations in the Context or
>does it eat it.  If the former is true, then the MGC would have to set the
>Mode to Inactive while looking for an inband tone.  If the latter, then
>clarification could be made that the TerminationMode does not apply to
>Signals and Events.  As far as I can tell there is no text in the draft
>that says this.

   Well, I'd suggest Mode=ReceiveOnly that ISN'T waiting on a tone Event
should certainly pass on the tone.  (Isn't that a reasonable condition for
PSTN connections prior to answer??  The caller had better hear something.)
And given Brian's distaste for Notify triggering an ACTION in an MG, then
it would appear Mode=ReceiveOnly WAITING FOR A TONE had better act the same
as Mode=ReceiveOnly NOT WAITING FOR A TONE.

Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 11 Oct 1999 16:53:34 -0400

I'm a bit slow to reply to this, what with travel and a long weekend, so I
hope my comments aren't redundant.

> -----Original Message-----
> From: Christian Groves [SMTP:[email-masked]]
> Sent: Thursday, October 07, 1999 4:41 AM
> To:   [email-masked]
> Hello Brian,
> I was just trying to offer some advise to IANA so that certain names are
> reserved. ie. If I take out a whole lot of names starting with FORE will
> FORE be very happy? It would like to see that people can't register
> packages called ITUxxxx.
        [[TomT]]
        Major point is that we want short package names.  The rules IANA
uses are those we write, so we can always say that package names should not
include organization designators.  We could specify that IANA record the
submitting organization, and pointers to documentation where the package
description is intended to be public.

> You raise an interesting point about the private company registered
> (proprietory)
> Packages. Should they have to make any private documents referenced
> publically available? I'm not sure of the IETF/IANA rules here.
        [[TomT]]
        As I said above, we make the rules.  The issue is really one of
reserving name space -- if someone wants to use a private package, they do
so in the knowledge that they will not be fully interoperable with other
vendors.  It is in the general interest to prevent name collision, and that
is the basic purpose of IANA registration.

> With regards to package name. As you've mentioned that it should be a
> short
> name is the 64 characters defined in the ABNF too long.
>
> I don't agree that you should support all the values in a Package. For
> example codecs (yes I know there could be a completely seperate package
> but not in this example). This is a property with values. Certain
> vendors will support certain sets of codecs for a given application.
> Does this mean that each will have a different package name for
> essentially the same application. The vendors equipment supports all
> properties but may not support 1 codec out of 10 possible codecs. To me
> you use the same package name - its a sign that the MG supports a group
> of functionalities. If you had a different package for each grouping of
> values then you have potentially 10! packages (>300000).
        [[TomT]]
        There are several ways we could handle this, none of which lead to
the combinatorices you suggest.  The one I favour is to give special
treatment to codecs -- their support is indicated in the SDP or native-mode
media descriptors returned from audits, and not by listing packages
supported.  As an alternative one could have a package for each codec, but
this just replaces codec names as listed in the RTP profiles with another
set of names.

        [[TomT]]  ...

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 12 Oct 1999 15:49:39 -0400

Second try.

> From: Taylor, Tom-PT [CAR:B904-I:EXCH]
> Sent: Monday, October 11, 1999 4:52 PM
> Subject:      RE: Packages Conference Call Minutes
>
> Major point is that we want short package names.  The rules IANA uses are
> those we write, so we can always say that package names should not include
> organization designators.  We could specify that IANA record the
> As I said above, we make the rules.  The issue is really one of reserving
> name space -- if someone wants to use a private package, they do so in the
> knowledge that they will not be fully interoperable with other vendors.
> It is in the general interest to prevent name collision, and that is the
> basic purpose of IANA registration.
>
> There are several ways we could handle this, none of which lead to the
> combinatorices you suggest.  The one I favour is to give special treatment
> to codecs -- their support is indicated in the SDP or native-mode media
> descriptors returned from audits, and not by listing packages supported.
> As an alternative one could have a package for each codec, but this just
> replaces codec names as listed in the RTP profiles with another set of
> names.
>
> [[TomT]]  ...