Subject: [Megaco] TerminationID to CIC mapping in case of H.248/ISUP interoperation

From: Ariel Burbaickij <[email-masked]>
Date: Thu, 9 Feb 2006 13:19:08 +0100

Hello dear mailing list partcipants,
I have following question regarding the best/supported  practices
for TerminationIDs naming. RFC 3015 does not go in much
detail as about schema(s) to use in provisioning of TerminationIDs.
It just writes:

   Terminations are referenced by a TerminationID, which is an arbitrary
   schema chosen by the MG.

   TerminationIDs of physical Terminations are provisioned in the Media
   Gateway. The TerminationIDs may be chosen to have structure.  For
   instance, a TerminationID may consist of trunk group and a trunk
   within the group.

Now we would like to have our CICs as Terminations without introducing
any database with mapping between TerminationID and (SignalingPointCodes,CIC)
pair. The mapping should be derivable from TerminationID directly without
the necessity of lookup in the database. Is this approach supported and
where I can read more about large scale (approx. 500 000 CICs or voice lines
how ever you would like to call them) TerminationIDs provisioning in
the databaseless fashion in particular and about best practices for
large
H.248 deployments in general?

Thank you very much in advance.

With Best Regards
Ariel Burbaickij

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 10 Feb 2006 12:44:45 +1100

Hello Ariel,

Profiles can describe such mapping. You may want to take a look at the 
ETSI Tispan defined:

Draft ETSI ES 283 024: "H.248 Profile for controlling Trunking Media 
Gateways"

it provides a termination schema for TDM terminations.

Regards, Christian

---

From: Ariel Burbaickij <[email-masked]>
Date: Sat, 11 Feb 2006 14:20:57 +0100

May I ask you for a favour of sending me the copy of the draft as
I have have diffculties to find it on ETSI site and DVD with allegedly
all drafts etc. from ETSI will arrive only later next week.

With Best Regards
Ariel Burbaickij

---

From: [email-masked]
Date: Sun, 12 Feb 2006 10:45:55 +0100

Ariel,

like to add some info.
The TerminationID (by ETSI 283 024) scheme with it hierarchy and interface
type flexibility is for the IDENTIFICATION of TDM Terminations (here
circuits).

I'm not sure whether this was your real question?
> ..without introducing any database

A "database-less" approach (on MGC level) for physical Terminations is NOT
possible for real applications in my understanding. Beside the table for
call-to-bearer IDENTIFICATION ("CIC mapping") you also have to consider (at
least) also bearer-related STATE information (e.g., H.248 "ServiceState" of
a Termination; management states like blocked etc, see eg X.731; or usage
state info like idle or seized).

What's again you specific concern?

Albrecht

                      Ariel Burbaickij                                                                                                 
                      <ariel.burbaickij         To:      Christian Groves <[email-masked]>                              
                      @gmail.com>               cc:      [email-masked]                                                               
                      Sent by:                  Subject: Re: [Megaco] TerminationID to CIC mapping in case of H.248/ISUP               
                      megaco-bounces@ie         interoperation                                                                         
                      tf.org                                                                                                           

                      11.02.2006 14:20                                                                                                 

With Best Regards
Ariel Burbaickij

---

From: Ariel Burbaickij <[email-masked]>
Date: Sun, 12 Feb 2006 20:00:05 +0100

> type flexibility is for the IDENTIFICATION of TDM Terminations (here
Yes, at least from the explanation it looks like what we are looking for.
I need to read the draft before coming to final decision, surely.
> state info like idle or seized).
Yes, I understand this. But state related information is normally contained
in the main memory with ocassional saving on the permanent storage medium
which is fine. My concern is about provisioning the mapping between
the CIC+SPC pair and termination ID. I would prefer approach where
I am able to define some kind of mapping formula and then the
termination ID is calculated on the fly on per CIC+SPC base.
>From 500 000 CICs on it is rather hard to justify one additional
database to be maintained.