Subject: [Megaco] Some questions on H.248.26 "Basic CAS Packages"

From: "Kamitses, Jerry" <[email-masked]>
Date: Tue, 19 Jul 2005 19:31:35 -0400

A few questions have arisen during interop testing regarding events 
and signals in the Basic CAS Packages in H.248.26.

 	- - -  - - -     - - -   - - -     - - -   - - -  
Question 1: This question concerns the meaning of "timed transition" 
as used in the descriptions of the Seizure and Answer events:
   "The event is reported by the MG if either the timed transition 
     to this line signal is detected or the line signal already exists."

In the case of the Answer signal, we understand this to apply to trunks 
which do not use answer supervision. On these trunks a transition to the 
answer state is assumed to occur after a suitable delay following the 
completion of digit out-pulsing (as long as the calling party remains 
off-hook).

What does "timed transition" mean for the Seizure signal? Is this meant 
in the same sense as is used for the Answer event, or (perhaps) this is 
only meant to express the fact that the seizure signal must be present 
for a minimum period to be considered present? 

 	- - -  - - -     - - -   - - -     - - -   - - -  
Question 2. The Seize Ack event on wink start trunks is defined as 
	"reported when the trailing edge of the wink-start signal occurs".
In the Robbed Bit Signaling Package the event Pulse Off appears to have 
the same meaning for the for the initial wink-start. Are these events 
interchangeable for the initial wink on wink-start trunks that support 
both the BCAS and RBS packages? 

 	- - -  - - -     - - -   - - -     - - -   - - -  
Question 3. For out-going calls, we have a question regarding the following 
sample signal/event descriptors used to initiate signaling. The >>> <<< are used to 
flag the particular line in question.

  Signals {
    bcas/sz
  }
  Events = 12 {
    bcas/casf,
    bcas/sz,
    bcas/sza {
      Embed {
        Events {
          g/sc,
          g/cause,
          bcas/ans,
          bcas/casf
     >>>  bcas/idle <<<<
        },
        Signals {
          bcasaddr/addr {
            ds = "A2105554443E",
            NotifyCompletion = {TO,IBE,IBS,OT}
          }
        }
      }
    }
  }
The intended operation of this event descriptor is to initiate seizure;
then on detection of Seizure Acknowledge, to initiate out-pulsing of 
the bcasaddr/addr digit string and, at the same time, apply the set 
of requested events to detect/report one of:
	successful completion (g/sc), or 
	failure (g/cause, bcas/casf), 
followed by a subsequent detection of far-end answer (bcas/ans).

Our question concerns the correct handling of the bcas/idle event if it 
is included as indicated above. 

The definition of bcas/idle indicates that the event should be reported in the case 
that line signal (i.e. idle line signal already exists). 

The outgoing interface state at this point is seized, out-pulsing complete. The question 
concerns the incoming interface state at this point? Is it idle (so that the bcas/idle 
event, if present, would immediately be detected?)? 

An argument put forth for including bcas/idle at this point is that if out-pulsing fails,
and bcas/casf is detected/reported, then the MG also needs to detect/report bcas/idle to 
complete the unsuccessful outgoing call. It is not clear (to us) that this is a valid 
application the bcas/idle event. Could you please comment?

Also, are there any other aspects of the above sample event descriptor that are inconsistent 
with the intended BCAS event/signal semantics? 

For example, it appears (to us) that it would be invalid to request bcas/ans prior to 
receiving the seize ack,  but less clear whether it is valid to request bcas/ans after 
the seize ack but prior to the completion of out-pulsing? We have assumed this to be OK.

 	- - -  - - -     - - -   - - -     - - -   - - -  
Question 4. Some confusion exists as to the proper text encoding syntax
for the address digit string in the ds parameter of the bcasaddr/addr 
event and signal. 

This parameter type is defined as "string" in the package description.
The base H248 spec appears to define the ABNF encoding of "string" in
"ANNEX B.2: ABNF specification"
   String:  A string MUST use the quotedString form of VALUE and can
   contain anything allowable in the quotedString form.

Is this the definition of "string" that applies for the BCAS ds parameter,
(i.e. are quotes required?)

 	- - -  - - -     - - -   - - -     - - -   - - -  
Question 5. For an incoming BCAS interface, after the MG has detected/reported 
bcas/sz, the following sample event/signal descriptor is used to accept the 
incoming call setup:
  Signals {
    bcas/sza
  },
  Events = 12 {
    bcasaddr/addr,
    bcas/casf,
    bcas/idle
  }
Is it correct, depending on various error conditions, that both bcas/casf and 
bcas/idle as well as the combined pair are possibilities during incoming call 
setup?

 	- - -  - - -     - - -   - - -     - - -   - - -  
Question 6. Some confusion has arisen concerning the validity of simultaneously 
requesting a pair of events with opposite sense, e.g. requesting the pair of 
events casblk/blk and casblk/ublk in the same descriptor.  

Since a given circuit is in at most one such state at a time, then the first  
time such an event descriptor is received then one of the pair of events must 
be detected immediately.  However, after this, and assuming the eventBufferControl 
is OFF to allow generation of multiple notifies, then would subsequent state 
transitions to the applicable state cause additional detections?  

The question here, effectively, is whether the events that are used to detect 
line signal state transitions are "good for" at most one such detection per 
requesting descriptor or whether detection persists until the event is removed?

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