Subject: RE: [Megaco] Wildcarded Action Reply

From: Carl Rutter <[email-masked]>
Date: Mon, 8 Jul 2002 10:22:36 -0400

This seems to be a significant flaw.
If there are many contexts the transaction would be
way too big.  This also would happen on Audits etc.
Anyone have thoughts on how we avoid/work around this?

Carl

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Monday, July 08, 2002 1:36 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Megaco] Wildcarded Action Reply

G'Day Ron,

Unfortunately as you have pointed out the wildcarded only works on a command
level and not a context level. So in the case you point out the response
will be
larger than the requests. The original intention of w- responses was to
limit
the sizes of Audit responses.

Unfortunately unless there is a protocol change you'll get a long response
back
for commands with wildcarded (ALL) contextIds. 

Regards, Christian

Ron Stoughton wrote:
> 
> Greeting Megaconians:
> 
> If our MG desires to take an interface out of service that has active
> circuits engaged in calls on it, it very likely would send a command to
the
> MGC that looks like the following:
> 
>     MEGACO/2 <mg1.acc.com>:16384
>     Transaction = 6 {
>             Context = - {
>                     W-ServiceChange = DS1/3/1/* {
>                             Services {
>                                     Method = Forced,
>                                     Reason = 905
>                             }
>                     }
>             }
>             Context = * {
>                     W-ServiceChange = DS1/3/1/* {
>                             Services {
>                                     Method = Forced,
>                                     Reason = 905
>                             }
>                     }
>             }
>     }
> 
> My question is, what should I expect the transaction reply to look like?
I
> would prefer to receive something like the following:
> 
>     MEGACO/2 <xanadu>:2944
>     Reply = 6 {
>             Context = - {
>                     ServiceChange = DS1/3/1/*
>           },
>             Context = * {
>                     ServiceChange = DS1/3/1/*
>           }
>     }
> 
> However, the ABNF does not appear to provide a way to ask for a wildcarded
> action reply (e.g. by sending "W-Context = *"), so I think I am more
likely
> to get something like:
> 
>     MEGACO/2 <mgc.acc.com>:2944
>     Reply = 6 {
>             Context = - {
>                     ServiceChange = DS1/3/1/*
>           },
>             Context = 2 {
>                     ServiceChange = DS1/3/1/3
>           },
>             Context = 5 {
>                     ServiceChange = DS1/3/1/11
>           },
>             Context = 6 {
>                     ServiceChange = DS1/3/1/13
>           },
>             Context = 9 {
>                     ServiceChange = DS1/3/1/14
>           }
>     }
> 
> assuming the MG has 4 active terminations on the interface.
> 
> Is there any way to request a wildcarded reply?
> 
> Ron Stoughton
> [email-masked]
> 
> _______________________________________________
> 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: Carl Rutter <[email-masked]>
Date: Tue, 9 Jul 2002 09:41:43 -0400

Thanks,

We limit the wildcards to a T1 right now on our switch
so at most 24 replies would come back.

It would be nice to send back a transaction reply 
with a flag saying there is another transaction reply(same transaction #)
coming with more response data, or something like that??
This would then break the transaction ack etc.  But some concept
like this seems warranted??

Carl
-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Monday, July 08, 2002 8:22 PM
To: Carl Rutter
Cc: [email-masked]; [email-masked]
Subject: Re: [Megaco] Wildcarded Action Reply

G'Day Carl,

The work around would be to wildcard on a finer grain size. That way you can
manage the number of replies. The alternative is that the MGC shall known
the
relationship between Termination IDs and Contexts IDs and it can release
each as
appropriate.

Regards, Christian

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 9 Jul 2002 11:07:35 -0400

I have given some thought to application-based message segmentation (as
opposed to transport-based), and I haven't thought of a way to do it that
works real well, without adding a ton of new complexity.  Here are some
components of the "best" idea I have personally been able to come up with
(which really isn't saying much):

- a new "descriptor" that indicates more is coming, and gives a sequence
number.  This requires the sender to break transactions only in specific
places.  While the receiver will be able to reassemble the transaction, they
will not know when the transaction ends.

- a token to indicate "end of transaction" when it is broken across several
messages.  This allows the receiver to know it can assemble all the pieces
together and start processing.  

- a "partial ack" token, to allow senders to know when pieces have to be
retransmitted.

In order to make this all work, the sender would have to repeat the message
from the beginning all the way through the transaction id on EACH piece (for
example: "!/2 [1.2.3.4]:2944 T=12345{").  The new pieces would go INSIDE the
transaction, at the action level. ("...action reponse here}, TP{SEQ=1}}")  A
similar method could be used to segment long action replies.

Now, this all adds a lot of complexity to the protocol that hasn't existed
before.  It also requires application segmentation of protocol messages,
which also hasn't existed before.  I am not sure how wise it is to add
something this complicated to the protocol, and it certainly wouldn't happen
before v3 at the earliest, as tacking this on would break early v2
implementations.

I think that using more granular audits is the answer -- but only in some
cases.  Recovery from a catastrophic failure requires getting as much
information as possible, as quickly as possible.  The ability to segment
messages would be a great boon to that recovery effort, instead of trying to
audit pieces at a time.  I'm not so sure my thoughts are the best way to
achieve this segmentation, but I would like to eventually see something that
effectively allows us to generate/process long messages.

Kevin

-----Original Message-----
From: Carl Rutter [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 9:42 AM
To: 'Christian Groves'; Carl Rutter
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] Wildcarded Action Reply

Thanks,

Carl
-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Monday, July 08, 2002 8:22 PM
To: Carl Rutter
Cc: [email-masked]; [email-masked]
Subject: Re: [Megaco] Wildcarded Action Reply

G'Day Carl,

Regards, Christian

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 9 Jul 2002 11:07:35 -0400

Kevin

-----Original Message-----
From: Carl Rutter [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 9:42 AM
To: 'Christian Groves'; Carl Rutter
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] Wildcarded Action Reply

Thanks,

Carl
-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Monday, July 08, 2002 8:22 PM
To: Carl Rutter
Cc: [email-masked]; [email-masked]
Subject: Re: [Megaco] Wildcarded Action Reply

G'Day Carl,

Regards, Christian

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 09 Jul 2002 12:41:17 -0400

Hi,

         This is similar to "enumeration" and now come to think about it
this functionality could be defined as a package thus I don't see any reason
why can't it be added for any version, including v1.

For example, let say we define a package "split" for ROOT termination with
event "enum", event parameters "end = yes|no", "handle = <integer>" and
observed event parameters "end = yes|no", "handle = <integer>".
Where "handle = 0" from MGC means to start new enumeration.

Then at any time MGC can include Modify on ROOT with
Events = 123 { split/enum { end = no, handle = 0 }} and Audit { 
ObservedEvents }
in a (wildcard)  transaction which will direct MG to start "enumeration".
MG would return then reply with handle in Modify reply as
ObservedEvents = { split/enum { end = no, handle = 567 }}
and as many replies to the rest of the transaction as it can.
MGC then can repeat transaction request including Modify
with Events = 123 { split/enum { end = no, handle = 567 }}
and Audit { ObservedEvents } to continue, or
Events = 123 { split/enum { end = yes, handle = 567 }}
to stop enumeration. Also MG can reply to Modify with
ObservedEvents = 123 { split/enum { end = yes, handle = 567 }}
to let MGC know that there is no more replies.
MG can also send Notify with ObservedEvents in case there is
a long delay from MGC, or some kind of error to stop enumeration.

Additional "split/tmo=<integer>" property can be defined for ROOT
to control the delay time-out.
The package can also define "stale handle" error to report on stale
enumeration handles.
More over to speed up a process we can even define "expect=<integer>"
observed event parameter to let MGC know in how many iterations MG
expects the enumeration to be completed such that MGC can fire up
that number of transactions at the same time once it gets reply to initial
transaction with a "handle".

Comments?

Thanks.
         Aleks

At 11:07 AM 7/9/2002, Kevin Boyle wrote:

>places.  While the receiver will be able to reassemble the transaction, 
>they will not know when the transaction ends.
>
>- a token to indicate "end of transaction" when it is broken across 
>several messages.  This allows the receiver to know it can assemble all 
>the pieces together and start processing.
>
>In order to make this all work, the sender would have to repeat the 
>message from the beginning all the way through the transaction id on EACH 
>piece (for example: "!/2 [1.2.3.4]:2944 T=12345{").  The new pieces would 
>go INSIDE the transaction, at the action level. ("...action reponse here}, 
>TP{SEQ=1}}")  A similar method could be used to segment long action replies.
>
>something this complicated to the protocol, and it certainly wouldn't 
>happen before v3 at the earliest, as tacking this on would break early v2 
>implementations.
>
>messages would be a great boon to that recovery effort, instead of trying 
>to audit pieces at a time.  I'm not so sure my thoughts are the best way 
>to achieve this segmentation, but I would like to eventually see something 
>that effectively allows us to generate/process long messages.
>
>Kevin
>
>From: Carl Rutter [<mailto:[email-masked]>mailto:[email-masked]]
>From: Christian Groves 
>[<mailto:[email-masked]>mailto:[email-masked]] 
>
> > From: Christian Groves 
> [<mailto:[email-masked]>mailto:[email-masked]] 
>
> <https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mailman/listinfo/megaco 
>
> >
> <https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mailman/listinfo/megaco 
>
>
><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mailman/listinfo/megaco 
>

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 09 Jul 2002 12:41:17 -0400

Hi,

Comments?

Thanks.
         Aleks

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 9 Jul 2002 15:53:45 -0400

Here's some constructs I've attempted based on the description(text
examples... I'm not fluent in binary at this moment!):

1) !/2 [1.2.3.4]:2944
T=1{C=-{MF=Root{E=123{split/enum{end=no,handle=0}},AT{OE}}}
-- It is not apparent to me how this command solves the problem.  This does
not seem to perform segmentation of a particular transaction response, and
the audit is directed only at OE.

2) !/2 [1.2.3.4]:2944
T=1{C=*{MF=Root{E=123{split/enum{end=no,handle=0}},AT{OE}}}
-- This will return an error every time.  Root exists solely in Null and
Null is not part of *.

3) !/2 [1.2.3.4]:2944
T=1{C=*{MF=<termname>/*{E=123{split/enum{end=no,handle=0}},AT{OE}}}
-- This would have detrimental effects on existing Events descriptors on the
given terms.

I can only conclude that I do not properly understand what you are
proposing.  The idea of utilizing a package is attractive, becuase it means
that syntax changes are not required to the protocol.  But I am worried
about possible side effects on established events descriptors in the
meantime.  Perhaps some more explanation will clear this up for me...

Kevin
 
-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 12:41 PM
To: Boyle, Kevin [NCRTP:3R90:EXCH]; [email-masked]
Cc: Carl Rutter; 'Christian Groves'; [email-masked]
Subject: RE: [Megaco] Wildcarded Action Reply

Hi,

Comments?

Thanks.
        Aleks

Kevin 

-----Original Message----- 
From: Carl Rutter [mailto:[email-masked]] 
Sent: Tuesday, July 09, 2002 9:42 AM 
To: 'Christian Groves'; Carl Rutter 
Cc: [email-masked]; [email-masked] 
Subject: RE: [Megaco] Wildcarded Action Reply 

Thanks, 

Carl 
-----Original Message----- 
From: Christian Groves [mailto:[email-masked]] 
Sent: Monday, July 08, 2002 8:22 PM 
To: Carl Rutter 
Cc: [email-masked]; [email-masked] 
Subject: Re: [Megaco] Wildcarded Action Reply 

G'Day Carl, 

Regards, Christian

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 9 Jul 2002 15:53:45 -0400

1) !/2 [1.2.3.4]:2944

2) !/2 [1.2.3.4]:2944

3) !/2 [1.2.3.4]:2944

Kevin
 
-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 12:41 PM
To: Boyle, Kevin [NCRTP:3R90:EXCH]; [email-masked]
Cc: Carl Rutter; 'Christian Groves'; [email-masked]
Subject: RE: [Megaco] Wildcarded Action Reply

Hi,

Comments?

Thanks.
        Aleks

Kevin 

-----Original Message----- 
From: Carl Rutter [mailto:[email-masked]] 
Sent: Tuesday, July 09, 2002 9:42 AM 
To: 'Christian Groves'; Carl Rutter 
Cc: [email-masked]; [email-masked] 
Subject: RE: [Megaco] Wildcarded Action Reply 

Thanks, 

Carl 
-----Original Message----- 
From: Christian Groves [mailto:[email-masked]] 
Sent: Monday, July 08, 2002 8:22 PM 
To: Carl Rutter 
Cc: [email-masked]; [email-masked] 
Subject: Re: [Megaco] Wildcarded Action Reply 

G'Day Carl, 

Regards, Christian

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 09 Jul 2002 18:30:47 -0400

Hi,

         Sorry for not being clear.
As I indicated Modify is included "in a (wildcard) transaction", that is
a transaction that has wildcard(s) and thus potentially can be large.
Although it does not limit MGC to put it into non-wildcarded transaction
as well it will not do any harm in this case since it will manifest in
one enum iteration (that is reply will have "end=yes").
Since the order of command execution is guaranteed in a transaction
MGC shell place such Modify right before action to be "enumerated".
Thus we can even try to allow MGC to include several Modify commands
within one transaction which has multiple wildcarded actions. This might
complicate the matter so I'll leave it out for now up to the time package
to be worked on, if ever.

Here are simple examples of complete proposed text messages.

1.1 MGC includes Modify with handle=0 to instruct MG that it shell
start enumeration for this transaction which includes a wildcarded action.
It includes Audit descriptor with ObservedEvents token to be sure that
MG sends ObservedEvents descriptor with enumeration handle, e.g.:

!/1 [1.2.3.4]:2944
T=1{C=-{MF=ROOT{E=123{split/enum{end=no,handle=0}},AT{OE}}},
C=*{W-SC=*{MT=FO,RE=905}}}

1.2 MG starts enumeration, generates enumeration handle=567 and
sends it back in observed event descriptor along with partial
replies to wildcarded request. Lets assume MG has active contexts
5,6,7,8,9,10 and reply can only hold 4 of them, e.g.:

!/1 [1.2.3.5]:2944
P=1{C=-{MF=ROOT{OE=123{split/enum{end=no,handle=567}}},
C=5{W-SC=*},C=6{W-SC=*},C=7{W-SC=*},C=8{W-SC=*}}

2.1 Now MGC request to "continue enumeration" by including Modify with
returned by MG handle = 567 and setting end=no. Note that transaction
id is different from previous transaction, e.g.:

!/1 [1.2.3.4]:2944
T=2{C=-{MF=ROOT{E=123{split/enum{end=no,handle=567}},AT{OE}}},
C=*{W-SC=*{MT=FO,RE=905}}}

2.2 At this point there will be no more replies left after this, since MG
has only left to send replies for context 9 and 10, thus MG stops
enumeration, by sending back an observed event descriptor with
handle=567 and end=yes, along with rest of the partial replies
to wildcarded request, e.g.:

!/1 [1.2.3.5]:2944
P=2{C=-{MF=ROOT{OE=123{split/enum{end=yes,handle=567}}},
C=9{W-SC=*},C=10{W-SC=*}}

Enumeration complete, handle discarded.

Note: to be completely RFC compliant in the examples above
first reply should probably include error 533 "Max PDU reached"
as a last command reply, e.g.:

!/1 [1.2.3.5]:2944
P=1{C=-{MF=ROOT{OE=123{split/enum{end=no,handle=567}}},
C=5{W-SC=*},C=6{W-SC=*},C=7{W-SC=*},C=8{W-SC=*},
C=*{W-SC=*{ER=533{"Reached max, ask for more"}}}}

Now come to think about it, even without any package right now
for SeviceChange and Subtract in ALL Context MGC can simply
repeat same request (like it is done above but with no modify)
over and over again until it gets no replies at all, that is it gets
error 435 "no match", since MG will process for each request
as many terminations as it can include in the reply. Thus
eventually all terminations will be returned into NULL context
and no replies will be sent. But again, this would only work for
SC and S in ALL ctx while proposed package approach will
work for any command in any context.

This package can also include "split/compress=yes|no" property
which will act as analog to W-Command for Context. That is if MGC
sets split/compress=yes on ROOT then reply would look exactly as
Ron originally wanted it to be, e.g.
!/1 [1.2.3.5]:2944
P=1{C=*{W-SC=*}}

Thanks
         Aleks

---

From: Carl Rutter <[email-masked]>
Date: Wed, 10 Jul 2002 09:53:40 -0400

I believe this thread is going to be going on for awhile
as this won't be an easy nut to crack.

I think we need to address this as this issue will just
grow with time.  I'll throw out another idea for discussion:

We push the burden of this issue onto the MGC(the controlling entity)
If the MGC requests for example an AuditValue on all terminations in the ALL
context
and the MG internally determines that the Reply to this request will be too
large
for its transport mechanism, the MG with reply will an error code saying 
"700 - Requested Reply too Large"  or something like this.
As an example right now we only allow an AuditValue wildcards to the T1
level which limits
it to 24, so if it was wildcarded at the T3 we would send an error 700 on
this.
Maybe in the Error Reply we could somehow indicate what would be acceptable?

Comments,

Carl

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Wednesday, July 10, 2002 1:51 AM
To: [email-masked]
Subject: Re: [Megaco] Wildcarded Action Reply

G'Dy,

Whilst having this type of functionality in a package is an interesting
exercise
I'm a little concerned about the precedent that it is setting in that by
setting
a new event you modify the behaviour of the core protocol. ie. the MG rather
than sending replies in a single Transaction Reply must wait for additional
requests and responses. If multiple requests are responses are needed in
both
cases then the current mechanism of asking for a limited number of
context/terminations should be fine also. 

I agree that segmentation is an issue that needs to be looked at. My initial
thoughts would be that we have a layer under H.248/Megaco that could be a
general mechanism to achieve segementation where needed. ie. if you have
SCTP
you probably don't need it. It would be applicable to all versions of H.248.
Something like sect 7 of I.366.1 could be used for this purpose.

Regards, Christian

> MG sends ObservedEvents descriptor with enumeration handle, e.g.:
they
> > - a token to indicate "end of transaction" when it is broken across
several
> > In order to make this all work, the sender would have to repeat the
message
> > something this complicated to the protocol, and it certainly wouldn't
happen

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 15 Jul 2002 12:04:03 -0400

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, July 15, 2002 10:56 AM
To: [email-masked]
Cc: Aleksandr Ryabin; [email-masked]; Christian Groves; Carl Rutter
Subject: Re: [Megaco] Wildcarded Action Reply

Hi,

> >I think we should stick with one consistent interpretation and not only
> >include "match" tables for other commands, but rather have one match
> >table which will apply to all commands.
>
> I agree.

[CHH] I agree too.

And, the number of commands within a Context,  and the possible wildcarding
they may use in the TerminationIDs, should not affect the general solution
either.

> >2. I think that example you have will be handled by MG fine, since
> >first subtract will return all terminations which matchon T1/*
> >to NULL ctx and the second will match the rest, for example,
> >if T1/1 and T1/2 are in ctx 1, and T1/3 and T2/1 in ctx 2:
> >
> > Context = 1 { Subtract = T1/1, Subtract = T/2 },        ; result of
> > matching first subtract
> > Context = 2 { Subtract = T1/3 },                        ; result of
> > matching first subtract
> > Context = 2 { Subtract = T2/1 }                 ; result of
> > matching second
> > subtract
>
> Let's change the example a bit and assume that ctx 3 contains T2/2, and
> further assume the command was:
>
>     Context = * {
>         Subtract = T1/*,
>         Subtract = T2/*
>     }
>
> In this case, do you agree with Christer that the following reply should
be
> produced:
>
>     Context = 1 {
>         Subtract = T1/1,
>         Subtract = T1/2,
>         Subtract = T2/* {
>             Error = 431
>         }
>     }
>
> and that because the commands were not optional, processing would be
> terminated at the point of the error.

>
>
> Secondly, if the command were:
>
>     Context = * {
>         O-Subtract = T1/*,
>         O-Subtract = T2/*
>     }
>
> should the reply then be:
>
>     Context = 1 {
>         Subtract = T1/1,
>         Subtract = T1/2,
>         Subtract = T2/* {
>             Error = 431
>         }
>     },
>     Context = 2 {
>         Subtract = T1/3,
>         Subtract = T2/1
>     },
>     Context = 3 {
>         Subtract = T1/* {
>             Error = 431
>         }
>         Subtract = T2/2
>     }
>
> These examples are a bit contrived, but is useful to know whether there is
> any agreement on what the reply should look like.  I tend to view
wildcards
> as filters, and wonder whether the error indications are really necessary.

[CHH] I agree that it can be discussed if the error indications are really
necessary (especially if the O- prefix is used), but I think the important
thing is how the mapping for the VALID matches are done.

Ron's example also brings up another issue - in which order the commands are
executed. Ron assumes that for each Context the FIRST Subtract is first
executed for ALL of its TerminationID wildcard matches, THEN the SECOND
Subtract is executed for ALL of its TerminationID wildcard matches. That IS
the
most logical in my eyes, and I assume most people would agree, but it IS
important that there are NO missunderstandings about that.

[KJBII]  The spec makes no bones about command ordering -- commands shall be
executed in the order they appear.  This means that a wildcarded command
must be executed in its entirety before moving on to the next command.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 15 Jul 2002 12:04:03 -0400

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, July 15, 2002 10:56 AM
To: [email-masked]
Cc: Aleksandr Ryabin; [email-masked]; Christian Groves; Carl Rutter
Subject: Re: [Megaco] Wildcarded Action Reply

Hi,

[CHH] I agree too.

be

wildcards

Regards,

Christer Holmberg
Ericsson Finland