Subject: [Megaco] C-286: CAS Protocol Type Package

From: "Schwarz Albrecht" <[email-masked]>
Date: Thu, 28 Jun 2007 19:11:15 +0200

Just my comments raised from our verbal discussions per email:

The specific topic is basically related to physical terminations in
general, and not only to CAS terminations in my understanding.
Now, there is a specific call-to-bearer relation for H.248 physical
terminations, particularily concerning the used signalling system for
call control.
Bearer and call are therefor tightly-coupled (e.g. by a CIC in SS7).
The underlying call control signalling systems is thus of "static
nature", a quasi-permanent attribute of a physical termination.
(The "attribute value" of the physical termination would only change,
then the peer PSTN/ISDN equipment (e.g. terminal, access node, switching
system, CME, payphone, etc etc) would be changed (which is typically a
rather seldom event; I mean a change of the physical charateristics, the
call control signalling system and/or other stuff of a physical
termination).)

I think a good summary of that aspect might be the term
"Bearer-Dependent Call Control" (BDCC) behind a physical H.248
Termination (i.e. exactly the opposite concept of Bearer-Independent
Call Control, BICC).

Due to that, the MGC may get easily the knowledge about the BDCC-type of
a particular physical termination via a MGC level data base (and
configuration management).
The assumption here is a use case according your C-286, i.e. a MG
network position, whereby the X physical Terminations of the NULL
Context could be separated into multiple sub-sets x1, x2, ...xj, and all
X physical Terminations would be of the same type with regards to the
bearer technology (e.g. TDM, or analog line), and each sub-set xi would
relate to a specific BDCC-type (e.g. SS R1, SS R2, SS R5, etc).

Instead of a provisioned MGC level data base, the MGC could
alternatively built-up the information base via auditing such a
"termination attribute".
But then the property value would be provisioned in the MG, and the
characteristic would be "read-only".
This is my understanding of your contribution.

However, I got concerns when such a property would get "write access",
because this would e.g. mean that the MGC could dynamically change the
BDCC-type (which is implied to be used to control the bearer behind that
physical termination). Right?
I don't see the need for a *signalling* method here ...

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 29 Jun 2007 10:00:28 -0400

Frankly, I don't see the need for this at all.  MGs *must* know how to
operate their terminations.  The signaling system assigned to a
termination has actual physical characteristics that go beyond software
assignment -- R2 uses a 4 wire line state system, for example, while
typical POTS uses a two wire tip/ring system.  Both of these can be
considered CAS signaling scenarios.  It is clear that software
assignment will never turn a POTS line into an R2 channel -- that would
require adding physical hardware.  As such, protocol assignment becomes
impossible.
 
This is information that MUST be provisioned in the MG.  The MG will
need this information at boot time in order to initialize the
terminations correctly.  Remember that H.248 assumes that all
terminations are InService upon registration.  By requiring MGC
interaction to assign the "termination type", this is impossible.
Therefore, this methodology could be seen as violating the protocol.
 
Kevin

________________________________

From: Schwarz Albrecht [mailto:[email-masked]] 
Sent: Thursday, June 28, 2007 1:11 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Megaco] C-286: CAS Protocol Type Package

-Albrecht