Subject: [Megaco] Query regarding the wildcard response feature

From: [email-masked]
Date: Thu, 26 Sep 2002 16:17:18 +0530

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

---

From: Raphael Tryster <[email-masked]>
Date: Sun, 29 Sep 2002 16:31:48 +0200

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.  Local and remote descriptors are a problem, which I 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:

	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.

---

From: Raphael Tryster <[email-masked]>
Date: Sun, 29 Sep 2002 16:31:48 +0200

Media descriptor

Multiplex descriptor

Events descriptor

Signals descriptor

Digit map descriptor

EventBuffer descriptor

Statistics descriptor

Package descriptor

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]

	Hi Brian/Tom/List,

	Brian:

	Tom:

	Regards,
	Chintan...
	www.hssworld.com

---

From: "Harry Suede" <[email-masked]>
Date: Mon, 30 Sep 2002 13:49:27 +0800

Hi All

I just went through all the mails regarding the handling of the wildcard response and reached to the following conclusions

1. Since everyone is confused about the very concept of "W-", no one seems to have understood it.

2. Lack of enthusiasm in replying to the mail from Chintan (even from the leads of the mailing list), indicates that in general there is reluctance to implement this feature.

3. All the previous discussions on the mailing list have not led us to any substantial conclusion.

4. Raphael has definitely given some logical insight into this feature implementation but different vendors may have different view points. In this case either the guidelines for implementing this feature should be standardised or it should altogether be removed from the protocol.

- Harry

----- Original Message -----
From: Raphael Tryster
Date: Sun, 29 Sep 2002 16:31:48 +0200
To: [email-masked], [email-masked], [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 I 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 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

Package descriptor

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,

Brian:

Tom:

Regards,
Chintan...
www.hssworld.com

no responsibility for loss or dama!
ge arising from the use of the information

--

Sign-up for your own FREE Personalized E-mail at Mail.com

---

From: "Harry Suede" <[email-masked]>
Date: Mon, 30 Sep 2002 13:49:27 +0800

Hi All

- Harry

----- Original Message -----
From: Raphael Tryster
Date: Sun, 29 Sep 2002 16:31:48 +0200
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [Megaco] Query regarding the wildcard response feature

Media descriptor

Multiplex descriptor

Events descriptor

Signals descriptor

Digit map descriptor

EventBuffer descriptor

Statistics descriptor

Package descriptor

Raphael Tryster

-----Original Message-----

Hi Brian/Tom/List,

Brian:

Tom:

Regards,
Chintan...
www.hssworld.com

--

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 30 Sep 2002 09:56:38 -0400

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

alternation.&nbs p; Local and remote descriptors are a problem, which I
raised in my posting entitled "wildcard audit of media descriptor" on the
18th of September.

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, 

Tom: 

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 30 Sep 2002 09:56:38 -0400

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

Tom: 

clubbing 

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

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 30 Sep 2002 11:32:12 -0400

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 = *
   }
}