Subject: RE: [Megaco] Ia Profile - Treating a group of ephemeral terminations asa trunk

From: "Saurabh, Kumar" <[email-masked]>
Date: Fri, 17 Aug 2007 18:25:38 +0530

Hi Annie,

As opposed to ephemeral termination, I believe that an interface would
have a permanent existence and have a service state of its own.
Therefore in the given context, specifying NULL context for the
AuditValue command seems logical to me.

BTW, for specifying the interface you do not need wildcard for the <id>
field. ip/*/core is good enough.

-Saurabh

  _____  

From: Annie Benitez Pelaez [mailto:[email-masked]] 
Sent: Friday, August 17, 2007 09:19
To: [email-masked]
Subject: [Megaco] Ia Profile - Treating a group of ephemeral
terminations asa trunk

Dear H.248 experts,

Hi! As you know the ETSI TISPAN Ia profile defines a TerminationID
strucutre in the following format:

  <prefix>/<group>/<interface>/<id>

where <interface> may refer to a logical and/or physical interface.

In the case of a Border Gateway all terminations that we deal with are
Ephemeral terminations, and therefore the NULL context really does not
exist.

In certain implementation I imagine vendors will group certain number of
ephemeral terminations to a particular <interface>, and the need to
report failures on such interfaces arises. This is quite straight
forward as it is possible to send a wildcarded service change command to
indicate all terminations of a given <interface> are IS or OOS.

Now where it gets tricky, is if the controller would like to efficiently
Audit the state of a given interface. Typically in a TDM land one could
Audit the TerminationState of a wildcarded termination present in the
NULL context. Is that something that could be done in the case of
Ephemeral Terminations?

Transaction = 1 {

   Context = - {

      W-AuditValue = ip/*/core/* {

         Audit {

            Media {

               TerminationState {ServiceStates}}}}}}

or due to the fact that ephemeral terminations don't exist in the NULL
context cause this type of command to be invalid?

(now you couldn't put a "*" for the Context as that way you would get
too much information back, as we're looking for a simple IS/OOS
indication)

If it is invalid, then what would be an alternate mechanim to perform
such an Audit? 

One option would be to define an H.248 package (similar to the root
package), where the interface names could be returned, but I am not very
convinced about that option as it may not scale very well and I don't
believe a package is a way to go.

I would appreciate your input on this...

Best regards,

- Annie

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