Subject: RE: [Megaco] Query regarding the wildcard response feature

From: [email-masked]
Date: Tue, 1 Oct 2002 09:13:35 +0200

Hi,

It would be very nice if it can be as you write.

 Indeed there is no way in Megaco today to make a cleanup MG when MGC does
not care about current actives connections and simply wants to kill all of
them.

Unfortunately we already spoke about that a few weeks ago and the
conclusion was
that the answer will contain actual active context Ids and terminations in
these
contexts which are substracted. And in this cas if there are a lot of
contexts and terminations
the segmentation problem of  the reply will apply.

My conclusion is :

1- Wildcard has to be used with a lot of caution as you cannot know the
size of the response
     and there is no mechanism to solve the segmentation problem.

2- There is no way to make a cleanup MG in a simple way. This could be done
very easily
      with a SC Restart from MGC to MG for example.

I think that these two issues are really big problems in the context of a
carrier grade NGN network
with big MG's having thousand and thousand terminations.

Jean-Luc Lecuyer

Aleksandr Ryabin <[email-masked]>@ietf.org on 30/09/2002 17:32:12

Sent by:  [email-masked]

To:   "Tom-PT Taylor" <[email-masked]>, [email-masked]
cc:   "'Raphael Tryster'" <[email-masked]>, [email-masked],
      [email-masked]
Subject:  RE: [Megaco] Query regarding the wildcard response feature

Hi,

        Not sure if this W- case was already mentioned, or not:
Subtract with Context = * and TerminationId = *
Could usually be used on cold MGC boot to cleanup MG
when MGC does not care about current active connections and
it simply wants to kill all of them (see ex below)

Thanks
        Aleks

Kill all connections on MG:

MEGACO/1 [10.0.1.15]:2944
Transaction = 107367 {
  Context = * {
    W-Subtract = * {
      Audit {
      }
    }
  }
}

Expected response from MG:

MEGACO/1 [10.0.1.16]:2944
Reply = 107367 {
  Context = * {
    Subtract = *
  }
}

At 09:56 AM 9/30/2002, Tom-PT Taylor wrote:
Let me take this right down to basics.  I think you're on the right track
here by considering what we might expect to see, descriptor by descriptor.
Could we create use cases of where wildcarded audit replies would actually
be useful and where they would not, then consider limiting their scope?
If
we find that we never get anything sensible or useful by wildcarding, we
should simply deprecate the mechanism.

-----Original Message-----
From: Raphael Tryster mailto:[email-masked]]
Sent: Sunday, September 29, 2002 10:32 AM
To: [email-masked]; Taylor, Tom-PT [CAR:B602:EXCH];
[email-masked]; [email-masked]
Subject: RE: [Megaco] Query regarding the wildcard response feature

Having observed and taken part in some of these discussions, and noting the
level of detail in the messages, I have the impression that not many people
have actually tried to implement wildcard response, because if they had,
they might come to the conclusion that the method used has to be varied
according to the descriptor.  Here is my proposal:
Media descriptor
Never need more than one.  Termination state has 2 properties in the base
protocol.  Each of these can be expressed as name=val as Brian said.
Stream
descriptor is repeated for each different stream id and each different set
of values for its component descriptors.  There should only be one local
control descriptor per stream descriptor, with properties expressed as an
alternation.&nbs p; Local and remote descriptors are a problem, which
raised in my posting entitled "wildcard audit of media descriptor" on the
18th of September.
Multiplex descriptor
One descriptor for each muxtype.  Within the same muxtype, merge
termination
id lists.
Events descriptor
Repeated for each different request id.  Each descriptor is the union of
all
requests with the same request id.
Signals descriptor
Never need more than one.  The resultant descriptor is the union of all
signal requests for the terminations in the wildcard.
Digit map descriptor
Repeated for each different name or value.
ObservedEvents descriptor
Repeated for each different request id.  Assume all events are different,
as
they have a timestamp.
EventBuffer descriptor
Never need more than one.  The resultant descriptor is the union of all
event buffer requests for the terminations in the wildcard.
Statistics descriptor
Repeated for each different set of statistics values.
Package descriptor
Add each supported package to the same list.

Raphael Tryster
-----Original Message-----
From:   [email-masked] [SMTP:[email-masked]]
Sent:   Thursday, 26 September, 2002 12:47 PM
To:     [email-masked]; [email-masked]; [email-masked]
Subject:        [Megaco] Query regarding the wildcard response feature

Hi Brian/Tom/List,
I was going through the previous discussions on the mailing list for the
wildcard
response feature. I am still not clear at which level the clubbing of the
responses
should take place. Following are the excerpts of Brian's and Tom's mails.
Brian:
"I would do something like the following:-
     Enumerate the set of terminations covered by the command
     For each descriptor covered by the command
          For each potential item in the descriptor
               Determine the number of dissimilar values for each of
               the terminations
          Emit one descriptor
               For each item that is expressed as a property=value,
                    use the ALTERNATIVE construction to show all
                    dissimilar values
               For each item that is a simple list, show all values
                    in the list"

Tom:
"On a close reading of this last, however, I am inclined to believe that it
is the descriptors which are repeated.  The phrase "UNION of all the
individual responses" suggests a logical operation on fully-formed
responses

rather than something done by disassembling and reassembling them.  In
other

words, I think I was wrong earlier."
It appears from the above two mails that what Brian is suggesting is to do
a

clubbing
on the leafmost level i.e. at the individual item level. On the other hand
Tom
is suggesting
a clubbing on a descriptor level. Could you please clarify what is the
final

word on it?
Regards,
Chintan...
www.hssworld.com

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the
information

transmitted by this email including damage from virus.

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

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

---

From: [email-masked]
Date: Tue, 1 Oct 2002 09:13:35 +0200

Hi,

My conclusion is :

Jean-Luc Lecuyer

Hi,

Thanks
        Aleks

-----Original Message-----
From: Raphael Tryster mailto:[email-masked]]
Sent: Sunday, September 29, 2002 10:32 AM
To: [email-masked]; Taylor, Tom-PT [CAR:B602:EXCH];

Raphael Tryster
-----Original Message-----

Hi Brian/Tom/List,

Tom:

clubbing

word on it?
Regards,
Chintan...
www.hssworld.com