Subject: [Megaco] Subject: Responses to CAS Package Last Call comments

From: "Tom-PT Taylor" <[email-masked]>
Date: Sat, 24 Nov 2001 20:20:18 -0500

Kevin Boyle's original post got filtered out because it was too long.  I'm
forwarding it minus the HTML portion. -- Tom Taylor

From Kevin Boyle, sent Saturday Nov. 2 at 11:23 EST:

All,

Here are the responses to the comments received during last call on the CAS
packages.  Through review of the comments, we have made several editorial
and clarification changes to the document.  The draft will be reissued
imminently as draft-manyfolks-megaco-caspackage-02.

I have marked each response paragraph with [Authors] for ease of
discernment between comments and replies.

Kevin

Comments from Christian Groves, dated October 17, 2001:

COMMENTS TO H.248 CAS PACKAGE
These comments relate to draft-manyfolks-megaco-caspackage-01.txt

Section 4, introduction:
What is "feature group D (FGD) MF signalling single stage dialling". Does it
prevent overlap signalling?  Is feature group D a certain functionality
package in North America (like class 4, class 5 exchanges?)

[Authors] MF FGD signaling is one type of North American signaling
protocol and is applicable to class 3, class 4 and class 5 exchanges. This
protocol supports overlap outpulsing. 

What is "FGD operator services"? Is it assistance operators or trunk
offering operators or call centers?

[Authors] "FGD operator services" is referring to a type of FGD
signaling that is specific to operator call completion.

Section 5, 4th part:
"For some applications, CAS package provides all of the functionality
needed...". What is actually meant by "some applications"? Is functionality
missing for other applications? Is R2 counted as other applications?

[Authors] The bcas package does not provide the events/signals
required by all applications. The bcas package provides those events and
signals that are common. Functionality is missing for protocol specific
requirements, such as with R2. Extensions to the bcas package should be
defined for protocol specific requirements. There is a separate R2 package
currently under development.

Section 6.3.4, Event name Clear back; and also section 7:
Is "robbed bit signalling digital interface" the same thing as "bit stealing
in TS16 in T1" ? It seems to be something else knitted to the on-hook
condition on an access only ?

[Authors] Assuming you are referring to TS16 in E1, the robbed bit
signaling digital interface is the same as "bit stealing in TS16 in E1".
Robbed bit signaling digital interface also refers to bit stealing in a T1
interface. Can you clarify your question in the second sentence?

Section 6.6.1 Glare procedures:
Is glare exactly the same procedure as "double seizure" in R1/R2
specifications for ITU-T? 

[Authors] Yes, glare is also referred to as dual seizure or double
seizure.

Section 8.4.1 Ringback:
Is this signalling to the calling user from an assistance operator? This is
not covered in ITU-T R1 Rec.

[Authors] Yes, this is a signal from the operator towards the
calling user. This signal causes a ringback signal to be applied to the
calling user. This is a North American operator and emergency services
signaling requirement.

Section 9.3.1 Recall:
Is this the same as a reanswer signal from the called user? It seems to be
something else, since it is mentioned in the Operator services package.

[Authors] The recall signal is a request from the calling user
towards the operator which results in the "recall" of the operator into the
connection. 

Section 9 general:
All the operator services and signals mentioned, are not specified in ITU-T
R1 and R2. Are they all related to North American operator services? Why is
trunk-offering and canceling missing, or is that the same as "operator
attached" and "operator released"?

[Authors] The oses and osext packages are specific to North American
operator and emergency services.  New packages are required for the
definition of international operator requirements. Country specific packages
may be required.

Section 15.1 Basic single-stage MF or wink start or immediate start:
"Wink start" and "immediate start" is not part of the ITU-T R2 signalling ,
where "seizure acknowledgement" signal is always used and not part of ITU-T
R1, where "Delay dialling and start dialling (proceed-to-send) are used.
"Wink start sounds like a signal used nationally (or within a region).

[Authors] Yes, wink start is a North American signaling terminology.
The example provided is a North American protocol.

No reference:
Is also CAS signalling system number 5 and 5bis covered by this draft.
Where are the key pulses for transit and terminating indication specified?
In R1 and C5 the KP is like a normal MF digit. Is it regarded as a digit
also in this specification?

[Authors] The bcas package provides those events and signals that
are common to CAS protocols.  If there are C5 or 5bis specific requirements
beyond those events and signals provided in the bcas package, these
requirements should be provided in a new extension package. 

[Authors] The bcas package does not specify the format of the
address signal. The application builds the address signal as required, which
may include key pulses. The specification of key pulses, digits, etc., are
provided in other drafts. For example, the MF definitions are specified in
draft-bothwell-megaco-mftonepkgs-02.txt. 

In system C5 the line signals are compelled (like the register signalling in
R2). Is the intention that the MGW handles these compelled cycles
autonomously?

[Authors] Yes, the MGW handles the compelled cycles autonomously.
The R2 draft is heading in the same direction.

Comments from Maja Vukusic-Vasiljevski, dated October 20, 2001:

Comments on Megaco/H.248 Basic CAS Packages

These comments relate to draft-manyfolks-megaco-caspackage-01.txt

General:

1. From the package it is not clear what termination the MGC addresses for
requesting seizure / digits event notification. Is it a channel or a group
of channels? Either we add a parameter "speech channel id" in case events
are reported for the whole channel group or we should have logic in MGW,
which will attribute events (i.e. line signals from TS16) to corresponding
speech channels and notify the MGC about events related to each speech
channel separately. For example in call flow 15.1 it seems that MGC requests
notification of seizure and digits on the same termination, this shows that
authors' intention is to have such logic placed in MGW. Then these shall be
clearly explained in the document. 

[Authors] The termination the MGC addresses is the channel. With
TS16, the MG associates the line signals with the appropriate channel.
Clarification on the channel addressing will be added to the draft. 

2. It is not clear what triggers MGC request of notification of seizure and
digits events. If it happens at start up why not configure terminations to
be able to detect seizure and digits by provisioning? This should avoid
signalling from MGC to MGW.

[Authors] The MGC should always have control of event notification
(fundamental to Megaco). The trigger on the MGC is implementation dependent.

3. There is a need in strong and detailed argumentation of the requirement
for the MGC to be able to change provisioned values of the properties (see
first paragraph of subsection 6.2). Timers are defined in protocol variants
and their values are fixed there, these values cannot be changed arbitrarily
by a call. If any standard protocol does that it shall be explicitly stated
in the document. At least it should be clearly stated what is, if any, the
CAS variant that requires timer modification by the MGC

[Authors] The properties defined in the bcas package are signaling
attributes that can change on a per-call basis for one or more protocols.
Although it is unlikely these properties will frequently change, the ability
to change these properties based on the MGC's call knowledge is required.
Signaling attributes that do not change per-call have not been included as
properties in the bcas package. These attributes are provisioned in the MG. 

[Authors] Per section 6.2, the MG has a provisioned value for each
of the properties. The provisioned value is used by default. If the
properties defined in the bcas package do not change per-call for a given
protocol, the MG's provisioned value is used.

[Authors] There are no restrictions on the use of the properties in
the bcas package. Therefore, references to specific protocols have been
excluded. 

Section 4, introduction:

The terms should be preferably clear related to ITU-T standards. For example
what is the relation of single stage dialing and multistage dialing towards
en-block and overlap signaling.

[Authors] ITU is not all encompassing. There are countries that do
not use the ITU standards. The intent is to develop a baseline package
suitable to all countries and their protocols. The bcas package defines
abstract events and signals that are common to all protocols.  For those
protocols with requirements that extend beyond the baseline package,
protocol specific package extensions should be defined.  The introduction
section will be modified to clarify the intent of the bcas baseline package.

Section 5, Assumptions and Partitioning

*       Supervisory signaling assumes line signaling, is this correct? 

[Authors] Supervisory signaling provides instruction from the MGC to
the MG and applies to both line and register signaling. 

What does the "abstract events" have with the present standards and is it
correct to use such terms?

[Authors] Abstract event means the event provided is abstract in
relation to the various CAS protocols that build on it. Clarification will
be added to the introduction section. 

*       Further on, it is stated that "for some applications", the Basic CAS
package.....We think that the usage and the intention of the package should
be clearly and explicitly defined.

[Authors] The intention to provide a baseline package will be
clarified in the introduction section. The usage of the package should be
left to the developer.

Section 6.2:
Here is a general question of setting and modification of the properties. It
seems that a lot of properties, as well as the notification requests should
be set at configuration of the termination or tidying up the termination
with MGC logical call entities. This makes intensive MGC/MGW signaling. Is
this really needed if according to general concept, the signaling terminates
in the MGW? For example, can the "sztim" be the provisioned/default value
too?

[Authors] In reference to provisioning the notification requests,
refer to comment under "General", item #2.

[Authors] As stated in section 6.2, all properties have a
provisioned value in the MG. The MG uses this value by default. The MGC
writes a property value only if the value changes on a per-call basis for a
protocol.

Generally speaking, the packages seem to be implementation dependent, based
on the fact that some extent of the present MGC (call control) functionality
has been transferred to the MG.

"sdto" is for example OK to be changeable property.

"ansto" - it seems this timer in majority of cases belonged to the MGC/call
control. Is it the same as former "total time of register seizure/holding".
Could this be clarified please? What is the benefit and the reason of having
this on MGC?

[Authors] After further consideration, answer timing is best
performed by the MGC/call control. It will be removed from the package. 

Question1: Do we distinguish  "early B-answer" or this case is considered as
irrelevant / impossible? Couldn't we have PSTN on terminating side behaving
explicitly as today, comprising the notification mentioned above?

[Authors] This is dependent upon your implementation. You can do
this if you choose.

Question 2: Why the Release Guard validation time is not needed? (Even if
idle condition is on the line, the condition must persist for some time
before the acceptance)

[Authors] Release Guard Validation is protocol specific and not
common to all protocols. This should be addressed in a protocol specific
package extension. 

Question 3: The signal duration time at sending was defined in standards for
mainly all signals. Do we consider those values as provisioned in the MGW?
If yes, is this underlined enough in the draft?

[Authors] Signal duration should not be confused with the signal
detection time. The line signals in the bcas package do not have a duration
(not applicable). The line signals in the bcas package persist until the MGC
instructs the MG to apply a new line signal (i.e. until the line signal is
replaced). 

[Authors] The signal detection time, meaning the time a signal must
persist before being reported as an event, is provisioned in the MG. 

Question 4: Section 6.3.1, Description (and in other places too): What is
the case mentioned as "or the line signal already exists"?

[Authors] The leading transition of the line signal is not required
to detect and report the event. If the line signal is already present
(already exists), the MG shall notify the MGC of the detected event. 

Section 6.3.4: Is it possible to rename the "Clear Guard Timing"? Firstly
reading it seems as connected to the Release Guard signal?

[Authors] Clear guard timing is an appropriate description of the
parameter. Clarification will be added to the description of this parameter
to eliminate confusion with the Release Guard signal. 

"Clear Back" should belong to the standalone section, not in 6.3.4. Also,
what is the "Clear" signal in the description please (Clear back?)

[Authors] This will be corrected. "Clear" should read, as you have
stated, "Clear Back".

Section 6.4.1 /6.4.2 Is it duration for both cases provisioned/default?

[Authors] The duration is not applicable. The line signals persist
until replaced by a new line signal. Sections 6.4.3 and 6.4.4 will be
corrected to state a duration of not applicable.

Section 6.4.4. For some signaling the gap of 150 ms must be insured between
answer and clear back. Is this considered now as the MGW or MGC task? Such
gaps will be OK to mention at least.

[Authors] As a baseline package for all protocols, the bcas package
does not address protocol specific requirements such as a gap. Protocol
specific extension packages can address this.  

Section 6.4.5 Address signals seem to be fully aligned with R1. For R2 for
example, is it possible that the string is of only one digit?

[Authors] There are no restrictions on the number of digits included
in the address signal. The address signal can consist of one digit. 

Question: Standard R1 comprise waiting on the first address digit time after
sending of the seizure acknowledgement. On timeout the receiving/incoming
end will be blocked. Do we have such action in this case and where it is
performed (MGW?)

[Authors] The digit map provides a start timer (T) which is used
prior to the receipt of any digits. The MG reports the timer expiry which
the MGC can take action on. 

GENERAL and section 6.6.4: The handling of discontinuous signaling is not
enough visible. Is it included at all and is it considered within the MGW
provisioned signal parameters?
Chapter 6.6.4 state line signals should always last o the line. How is this
related to discontinuous signaling case? This case must not be treated as
error.

[Authors] Assuming you are referring to glitches, the MGW should
understand what is and what is not a valid transition for a signal received
from the far-end. The error procedures are referring to signals sent towards
the far-end as instructed by the MGC. A line signal should always persist.
The MGC should never instruct the MGW to remove a line signal with out
specifying a new (replacement) line signal.

Section 6.6.1: Better definition of the glare procedures, related to ITU-T
double seizure, is preferable.  "Gateways may have..." May is not proper
expression because includes optionality to have that glare element or not
and it is not clear how we get that options, based on what the option is
set. Up to now MGC knows who is controlling node based on the bilateral
agreement. Now this part of MGC functions is intended to be moved to MGW.
Now MGC is forced to back down the call by the seizure received from MGW in
any case.

How is with the case glare mechanism is not in the MGW?

[Authors] The optional terminology will be corrected. The gateway
"shall" have the configurable glare information element. Use of the term
dual seizure will replace glare.

[Authors] The glare element in the MGW simplifies the procedures
between the MGC and MGW and resolves issues related to signaling the start
dial (non-controlling) and detecting the start dial (controlling). A
consistent approach between internal and external glare is also provided.
With internal glare, the MGC must begin procedures to back down upon receipt
of the seizure notification (the start dial has already been signaled). The
MGC procedures align with this approach for external glare. 

Section 6.6.2 Why a mandatory time stamp. May that be optional?

[Authors] The time stamp is mandatory for billing requirements. 

Section 8.3 The signal is not completely clear, because it is not existing
in ITU-T R1. R1 has Ring Forward signal or called forward transfer signal.
Why this one is not a part of this package? Is this signal covered under
9.3.1 as the Recall signal? Is R1 signal "ring forward" skipped
intentionally in the list of events?

[Authors] The oses and osext packages are specific to North American
operator and emergency services signaling protocols.  Clarification will be
added to the package descriptions.

Comments from Asrar Ashraf, dated November 14, 2001:

     I want to implement a trunking gateway that will handle signaling from
a T1 source of CAS signaling with subtype of WinkStart.
     Now CAS is a basic type Package for any CAS signaling
    While R2 Package is for CAS-R2 Signaling ( I think a type of E1
Signaling)
    and R1 package is for CAS-R1 Signaling.
    
    All of these packages provide approx. same functionality so it is quite
difficult to select a particular Package out of these three to make a
Trunking Gateway that will be a Signaling as well as Media Gateway and
handling Trunk signaling of WinkStart subtype.

     Can any one guide me about this issue.

[Authors] The CAS package defined in
draft-manyfolks-megaco-caspackage-02 is a baseline for all CAS-based
signalling.  Basic R1 signalling should be possible using the base CAS
package, without need for a separate R1 package.  Any region-specific
variations of R1 will need an extension package defined.  R2 will be
possible to implement using the R2 package that is currently under
development.  When the R2 package is reissued, it will extend the CAS
package defined in caspackage-02, and have the overlaps removed.  So, while
the functionality in each package is related, it is not (will not be) the
same.

[Authors] If you don't need R2 extensions, and you are implementing
a generic flavor of CAS signalling, the base CAS package should be
sufficient.  If not, you will need the base CAS package, as well as the
specific extensions to achieve the specific CAS variant you are seeking to
implement.

Tom Taylor on behalf of Kevin Boyle
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

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