Subject: [Megaco] H.248.26 "Basic CAS Packages" Follow Up

From: "Kamitses, Jerry" <[email-masked]>
Date: Thu, 25 Aug 2005 13:35:55 -0400

Last month I floated a couple emails on the reflector soliciting input 
to help resolve a few questions regarding events and signals in the 
Basic CAS Packages in H.248.26.  Since, as yet, no one has offered any 
opinions on this topic I have concluded that one of the following 
must be true
  (1) the questions are considered too obvious to merit any response;
  (2) the relevant experts are still on summer vacation;
  (3) there are as yet no implementations of H.248.26 to use as a reference.

Consequently, I have reissued this email in the form of an answers (to 
my own questions). The intent here, which seems to be consistent with the 
spirit of this reflector, is that these answers become de facto clarifying 
extensions of the relevant standards, albeit I've yet to notice any instance 
of questions and their answers from one and the same person.  If this 
turns out to be deemed unsportsmanlike like I guess I'll hear about it?

Answers are included in-line set off with  chevrons ">>>"

	- - -  - - -     - - -   - - -     - - -   - - -  
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 = 13 {
          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). 

>>> CORRECT  <<<

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

>>> CORRECT. The bcas/idle event should be requested after the CAS call has been answered. <<<

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?

>>> If outpulsing fails then bcas/casf is detected and the circuit goes back on-hook. The 
ingress circuit remains idle (on-hook) at this point.<<<

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

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.
>>> This is 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?)

>>> CORRECT. Strings must be enclosed in quotes.<<<

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

>>> bcas/casf is required at this point in case of a failure when processing the 
bcas/sza signal.  bcas/idle is required in case the far-end goes back on hook
before completion of the input digit string occurs  <<<

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

>>> CORRECT. Generally the only time it makes sense for the MGC to request 
mutually exclusive events is if the MGC has lost synchronization with the 
termination state and wants to both determine the current state and simultaneously 
enable the detection of a state change. <<<

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?
>>> The event persists until it is removed <<<

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

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