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: Aleksandr Ryabin <[email-masked]>
Date: Mon, 08 Jul 2002 11:59:58 -0400

Hi,

         From practical point of view if an entity (ether MG or MGC)
wants a wildcarded response then it most likely wants it to be wildcarded
"as much as possible" (at least to avoid UDP packet size limitation errors).
Thus it is probably safe to agree that if W- is requested on command level
then it is propagated up to the context level. Then the reply would look like
Ron wants it to be below.

Can anybody think of any practical life scenario when an entity would
want to get a non-wildcarded reply on context level when command
level is wildcarded?

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 08 Jul 2002 11:59:58 -0400

Hi,

Thanks
         Aleks

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 10:22:19 +1000

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: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 10:22:19 +1000

G'Day Carl,

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 09 Jul 2002 08:14:50 +0300

Hi,

I would just like to comment the syntax of the message, and how it's understood by
the receiver:

The MG sends:

    Context = * {

Now, if there is a matching ContextID, which does NOT include a matching
TerminationID, an error will be generated.

So, to make this work I think the message would have to look like:

    Context = * {
         OW-ServiceChange = DS1/3/1/* {    // Note the O- prefix!!!
              Services {
                   Method = Forced,
                    Reason = 905
                }
         }
     }

Now, even if there is a Context without a matching Termination the processing will
go on.

Now, this does NOT solve Ron's original question, but I just wanted to mention it,
because I think it may be an important issue. I guess Ron assumed that Contexts
where BOTH the ContextID match AND the TerminationID match are valid will be
chosen(?). My understanding is that the ContextIDs and TerminationIDs will be chosen
separately from each other - ie every ContextID wildcard is chosen, no matter if it
includes a TerminationID wildcard match or not. Or, am I wrong?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 09 Jul 2002 08:14:50 +0300

Hi,

The MG sends:

    Context = * {

    Context = * {

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 10:22:19 +1000

G'Day Carl,

Regards, Christian

Carl Rutter wrote:
> MegaX-Mozilla-Status: [email-masked]

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 10:22:19 +1000

G'Day Carl,

Regards, Christian

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 09 Jul 2002 19:16:46 -0400

Hi,

         I believe the table in "7.2.5 AuditValue" as well as examples
there do indicate to match "both", that is an opposite of what you are
suggesting and in line with Ron assumptions:

    All       wildcard      Audit of all matching Terminations and the
                             Context to which they are associated
    All       Specific      (Non-null) ContextID in which the
                             Termination currently exists

The last line of table and examples are not in original RFC, they are in
v2 and 3015corr draft though, thus possible confusion.

Now, I have another confusion though. The last example is:

The command:
         Context=*{W-AuditValue=t1/*{Audit{Packages}}
Returns:
         Context=*{W-AuditValue=t1/*{Packages{aaa,bbb}}

Which implies that request for wildcarded response (e.g "W-" in
front of AuditValue) was applied to wildcarded Context.

So, now I'm confused: what should be returned here individual action replies
(thus example is wrong), or one with ctx ALL (thus Ron got his wish)?

Thanks
         Aleks.

PS BTW I think that it should be "O-W-Subtract" below (note dash after O)
and not "OW-Subtract".

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 09 Jul 2002 19:16:46 -0400

Hi,

The command:

Thanks
         Aleks.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jul 2002 07:42:16 +0300

Hi,

[CHH] First, Ron used ServiceChange (not AuditValue) in his example, and for that
we don't have a similar "match table". I think we should have a look if the table
in 7.2.5 could be used also for other commands (eg ServiceChange and Subtract).

Also, the table may work fine as long as there is a one-to-one Context/Termination
matching. But, what about the following example:

Context = * {
    Subtract = T1/*,
    Subtract = *
}

Now, when do we now have a match? When all matching Terminations for BOTH Subtracts
and the Context to which the are associated match?

> PS BTW I think that it should be "O-W-Subtract" below (note dash after O)

[CHH] Correct. My misstake.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jul 2002 07:42:16 +0300

Hi,

Context = * {
    Subtract = T1/*,
    Subtract = *
}

Regards,

Christer Holmberg
Ericsson Finland

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 10 Jul 2002 12:44:18 -0400

Hi,

1. I'm not sure if you are implying that MG semantics of matching will be 
different
depending on the command, or just stating that "match" tables are not there.

1.1 If first, then that seems rather inconsistent and confusing as both MG and
MGC has to have different algorithms for different commands.
And then what MG will do if let say in the following case:

Context = * {
     AuditValue = T1/*,
     Subtract = T1/*
}

It will be a total mess since for AuditValue MG will try to return only 
contexts
that matches both, but for Subtract it will match ether?

1.2 If second and match semantics should be the same for all commands
> > (thus example is wrong), or one with ctx ALL (thus Ron got his wish)?
Any takers, please?

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.

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

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 10 Jul 2002 12:44:18 -0400

Hi,

Context = * {
     AuditValue = T1/*,
     Subtract = T1/*
}

Any takers, please?

Thanks
         Aleks

---

From: Ron Stoughton <[email-masked]>
Date: Wed, 10 Jul 2002 13:52:03 -0400

Hi Aleks,

> table which will apply to all commands.

I agree.

> Context = 2 { Subtract = T2/1 }                 ; result of

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.

Regards,

Ron Stoughton
[email-masked]

---

From: Ron Stoughton <[email-masked]>
Date: Wed, 10 Jul 2002 13:52:03 -0400

Hi Aleks,

I agree.

    Context = * {
        Subtract = T1/*,
        Subtract = T2/*
    }

    Context = 1 {
        Subtract = T1/1,
        Subtract = T1/2,
        Subtract = T2/* {
            Error = 431
        }
    }

    Context = * {
        O-Subtract = T1/*,
        O-Subtract = T2/*
    }

    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
    }

Regards,

Ron Stoughton
[email-masked]

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 10 Jul 2002 15:21:56 -0400

Hi,

If we match "any" (that is context or termination) then I agree with your 
examples.

If we are to be consistent across all the commands and say that we match
"both" (that is context and termination) then a reply to command with
wildcarded termination and wildcarded context will never contain error 431
except the case when there are no matches at all.

That is for your modified example:
Context = * { Subtract = T1/*, Subtract = T2/* }

If T1/1 and T1/2 are in ctx 1, and T1/3 and T2/1 in ctx 2, and T2/2 in ctx 3
reply would be:

Context = 1 { Subtract = T1/1, Subtract = T1/2 }, ; result of matching 
first subtract
Context = 2 { Subtract = T1/3, Subtract = T2/1 }, ; result of matching 
first and second subtract
Context = 3 { Subtract = T2/2 }                 ; result of matching second 
subtract

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 10 Jul 2002 15:21:56 -0400

Hi,

Thanks
         Aleks

---

From: Christian Groves <[email-masked]>
Date: Thu, 11 Jul 2002 16:33:43 +1000

G'Day,

I tend to agree with Ron in questioning whether the error code is useful in
these cases. The text that Aleks proposed, "a reply to command with wildcarded
termination and wildcarded context will never contain error 431 except the case
when there are no matches at all." I think is a good clarification that could be
included in H.248.8 (Annex L).

Still the main issue is the Wildcard W- and if it pertains to a context. For
AuditValue it seems that the "desired" correct behaviour is defined in 7.2.5 for
Wildcard response. This is countered by the fact wildcarded responses are
described in 6.2.2 which describes terminationIDs and the fact that (W-) is on a
command level. So its not as clear cut as my original email to the start of this
thread.

So the question we need to answer is: Do we want to add text to the
Implementors' Guide clarifying that the behaviour of 7.2.5 applies to all cases
of responses Context=All, Wildcard=t1/* ?

If not we need to fix the apparent contradiction between 7.2.5 and 6.2.2.

Any comments by the people who originally helped formulate the IG addition on
this?

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 11 Jul 2002 16:33:43 +1000

G'Day,

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Jul 2002 17:55:46 +0300

Hi,

> >table which will apply to all commands.

[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.

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

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Jul 2002 17:55:46 +0300

Hi,

[CHH] I agree too.

Regards,

Christer Holmberg
Ericsson Finland