Subject: [Megaco] Megaco/H.248 Basic CAS Packages

From: "Maja Vukusic Vasiljevski (ETK)" <[email-masked]>
Date: Sat, 20 Oct 2001 11:30:48 +0200

Hello,
here we have some comments or the questions for the clarification on the Megaco CAS packages. Please find them  below under each draft indication.

Kind Regards/Maja Vukusic-Vasiljevski , Ericsson

Comments on Megaco/H.248 Basic CAS Packages

These comments relates 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. 

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.

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.

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.

Section 5, Assumptions and Partitioning

*	Supervisory signaling assumes line signaling, is this correct? What does the ”abstract events” have with the present standards and is it correct to use such terms?
*	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.

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 tiding 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?

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?

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?

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)

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?

Question 4: Section 6.3.1, Description (end in other places too): What is the case mentioned as “or the line signal already exist”?

Section 6.3.4: Is it possible to rename the ”Clear Guard Timing”? Firstly reading it seems as connected to 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?)

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

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.

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?

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?)

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.

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?

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

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?

Some COMMENTS ON draft-ietf-megaco-r2package-02.txt

This draft generally follows implementation (requirements???) assumptions. Signaling link ending in MGW request bounding of signaling info with the voice channel designation, what is not explicitly described or referred to another document.
Further, it reallocates a part of MGC call control functionality to the bearer network (server logic moved to the gateway) - as number length determination, independent handling of the signaling in (group A, I) in the MGW with provisioning of the expected digit map from the MGC. With this handling some signals are not present any more as for example the request for n-1, n-2 etc. digit. What if PSTN ordinary combined node provides that info backward to the MGW? Do we restrict actual behavior of the system? It might be the case that MGW connected to old CAS network will not be able to provide all digits or the category, or that the call might be routed with lower number of digits, but digits are kept in MGW. This functional allocation request very coordinated provision of data and it is ok because decreases the number of MGW-MGC signaling, but does not allow the system a backward compatible behavior.

It will be ok if package definition allows transfer of data in both direction between MGW and MGC, independently of the functional allocation (e.g. one by one digit with backward requests from MGC and as proposed in the draft as the whole address info).

Section 4: Introduction:

We do not understand fully the reason why “ trunk offering, re-ringing, reanswer...” is treated as completely not standard when we have standardized some operator signals within bcas draft. At least that might be covered by another draft.

Section 5:

Is end-to-end handling anyhow lost as an option of standard behavior within this draft?

Section 6.2, trdir: Do we need separate indication for test routes too (like test inco, etc), what was separatly known as a possibility in the conventional nodes? Anyhow, what was the importance and the intention of this knowledge in the MGW at all?

Section 6.3.2 The Calling Subscriber Category velues  do not seem fully compliant to ITU-T values. Can this be aligned please?

Section 6.5.1. Is it this applicable only for R2? It seems not. If needed, proper allocation might be in the basic package.

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