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

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 25 Aug 2005 14:23:26 -0400

Here are answers to the original email.  I had to research some stuff,
and then would get sidetracked on other things (vacation, other work,
etc.)  Sorry for the delay.

Comments inline. [KJBII]

Kevin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Kamitses, Jerry
Sent: Tuesday, July 19, 2005 7:32 PM
To: [email-masked]
Subject: [Megaco] Some questions on H.248.26 "Basic CAS Packages" 

A few questions have arisen during interop testing regarding events and
signals in the Basic CAS Packages in H.248.26.
[KJBII] BCAS is in H.248.25.

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

[KJBII] Most, if not all, of the CAS signals have a minimum duration to
suppress spurious voltage fluctuations.  The words "timed transition"
were chosen to indicate that the event cannot be detected upon a
momentary change of voltage, but must actually exist for the minimum
duration.

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

[KJBII] These are interchangeable as long as the duration of Pulse Off
is long enough to detect Wink Starts.

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

[KJBII] I observe from your message that the Events Descriptor in
question is activated upon detection of a SeizeAck.  This means that the
far-end Seized the circuit.  I can't see how the far-end would be idle
at this point, unless it released the circuit. If it was, and the line
state is, in fact, idle, then yes, that would be immediately reported.

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?

[KJBII] I would think that if the far-end idles the circuit, the MGC
would want to know about it.

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.

[KJBII] The MGC can request detection of whatever it wants at any time.
Whether it is possible to detect the event in question is a completely
independent question.  If the MG knows that the event cannot occur, then
it just won't report it, right?

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

[KJBII] Yes.

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

[KJBII] Failure is always a possibility for a myriad of reasons, some of
which are external influences on the network that are unpreventable.  I
would also assume that it is possible for the far-end to idle the
circuit as well.  I don't see any problem with asking for these two
items to be present.  If there is a conflict in meaning, it is up to the
MG to figure out which event (or both!) is appropriate.

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

[KJBII] In H.248, Events Descriptors are valid and active until they are
replaced if EventBufferControl is OFF.  So the short answer is that
detection persists.

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

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