Subject: RE: [Megaco] Megaco CAS

From: "Kevin Boyle"<[email-masked]>
Date: Fri, 25 Jan 2002 14:14:51 -0500

All,

We have a new version of the draft that is awaiting IANA registration before
I publish it again.  We will include the coding parameter as optional, as
suggested.

As to other comments in the thread... the package does not define the
granularity of any provisioning (either per-term, or per-MG).  This was
worded intentionally to avoid imposing an implementation upon an MG.  For
certain items, it should be apparent to the vendor what type of provisioning
is appropriate, given the implementation. I can envision per-MG, per-DS0, or
even per-group-of-DS0s.

And, the statement about attempting to force DTMF over an MF trunk is
certainly outside the scope of CAS.  However, the addition of the coding
parameter will allow this behavior, if desired.

Kevin

-----Original Message-----
From: PSK Chakravarthi [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 3:17 AM
To: [email-masked]; Al Varney
Subject: Re: [Megaco] Megaco CAS

Al Varney,

I think optional is OK.  Default coding type for a termination should be
provisioned in MG.  If MGC want to override, it can use optional parameter
"ac".

Thanks
Chak
----- Original Message -----
From: "Al Varney" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 09, 2002 10:18 PM
Subject: Re: [Megaco] Megaco CAS

> Chak,
>     At first, I thought the Description of "provisioned" frequency,
> cadence, etc. could be clarified as a per-trunk attribute (not per MG, as
> some might read it).  That is, MF trunks always used MF signaling, etc.
On
> further reflection, this is insufficient to emulate some forms of older
> signaling used in the USA.  For example, some circuits signal using Dial
> Pulse in a first stage, followed by MF in the second.  Also, it might be
> useful to force DTMF signaling over an MF trunk which is already connected
> on a call (although that goes beyond the function typically associated
with
> the acronym "CAS").
>
>     So I'm agreeing with you, with a small suggestion below:
>
> At 12:56 PM 1/9/02 +0530, PSK Chakravarthi wrote:
> >I think we can have another parameter as given below:
> >
> >         Parameter Name: Address Type
> >         ParameterID: at (0x0003)
> >         Description: Specifies Type of address digits.
> >         Type: enumeration
> >         Possible Values:
> >         "DTMF"  (0x0000)  DTMF Digits
> >         "MF"       (0x0001)  MF Digits
> >         "DP"        (0x0002)  Dial Pulse Digits
>
>     It might be less confusing if the word "Type" was not used in the Name
> or Description, since it is part of the meta-language of MEGACO
> packages.  I used "Coding" below, but another word might be better.  Also,
> you offered no default text in the Description -- did you really want
> "Address Type" to be included in every use of "addr"?
>
>       Alternative Name/ID/Description for consideration:
>   Parameter Name: Address Coding
>   ParameterID: ac (0x0003)
>   Description: Specifies the coding of Digit String parameter
>            in tones or DC pulses.  Address Coding is optional;
>            if not provided, the MG uses the value provisioned
>            as an attribute of the circuit associated with the
>            signal.
>
>     Would it be useful to mention an error case if Address Coding is not
> present and the "circuit" has no 'ac' value provisioned?  (For example,
> could CAS package be used to signal over an ephemeral?)
>
>     On second thought, having 'ac' optional might be a mistake.  It forces
> the MGC to "know" the coding for every circuit.  (The
> provisioned-per-MG-circuit option allows the MGC to be ignorant of the
> coding.)  I think it unlikely that the MGC could be ignorant of MF vs.
DTMF
> vs. DP for a given circuit, and provisioning in 2 places (MG and MGC) is
> just asking for an error.
>
> Al Varney - [email-masked]
>
> > > From: PSK Chakravarthi [mailto:[email-masked]]
> > > Hi List,
> > > As per draft-manyfolks-megaco-caspackage-01.txt Section
> > > 6.4.5
> > >     Signal Name: Address
> > >     SignalID: addr (0x0005)
> > >     Description: Applies the address signals in the form of either
> > >           DTMF, dial-pulse or MF-tones on the trunk. The actual
> > >           frequency, cadence, duration and amplitude values for the
> > >           multi-frequency tones that convey the address information
are
> > >           provisioned in the MG.
> > >     Signal Type: (BR) Brief
> > >     Duration: Provisioned
> > >     Additional Parameters:
> > >         Parameter Name: Digit String
> > >         ParameterID: ds (0x0001)
> > >         Description: The digit string that needs to be sent as address
> > >           signals.
> > >         Type: string of digits.
> > >         Possible Values: a sequence of the characters "0" through "9"
> > >           as well as "A" through "H" ("A" through "H" used for MF
> > >           signalling - refer to the symbols defined for the digit map
> > >           in the MF Tone Detection package).
> > >         Parameter Name: Address Delay
> > >         ParameterID: ad (0x0002)
> > >         Description: Specifies a timed delay that is applied prior to
> > >           signalling the address. The address delay is optional. If
the
> > >           address delay parameter is not provided, the MG uses the
> > >           provisioned value by default.
> > >         Type: integer
> > >         Possible Values: 0 and up in milliseconds
> > >
> > > Question:
> > > MGC can instruct gateway to out pulse digits either in DTMF or MF or
dial
> > > pulse.
> > > How MGC can tell gateway about the mode of the digits is MF or DTMF or
Dial
> > > Pulse?
>
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco