Subject: [Megaco] Wildcarding principles

From: Terry L Anderson <[email-masked]>
Date: Fri, 18 Oct 2002 12:47:12 -0400

At the Geneva meeting we are considering the following Implementors
Guide item to address several of the items concerning Wildcards that
have appeared recently on the list.  Note that it modifies 6.2.2 as
shown and adds 6.6.  This is a D-283 submitted to the meeting as modifed
during an editing session.

6.2.2    TerminationIDs
Terminations are referenced by a TerminationID, which is an arbitrary
schema chosen by the MG.
TerminationIDs of physical Terminations are provisioned in the Media
Gateway. The TerminationIDs may be chosen to have structure. For
instance, a TerminationID may consist of trunk group and a trunk within
the group.
A wildcarding mechanism using two types of wildcards can be used with
TerminationIDs. The two wildcards are ALL and CHOOSE. The former is used
to address multiple Terminations at once, while the latter is used to
indicate to a media gateway that it must select a Termination satisfying
the partially specified TerminationID. This allows, for instance, that a
MGC instructs a MG to choose a circuit within a trunk group.

6.6 Wildcarding Principles
This clause specifies the behaviour for wildcarding Context and
Termination Identities that shall be applied to all commands. In
processing these commands two forms of wildcarding must be considered:
1.    Context Wildcarding
2.    Termination Wildcarding
In the case when the ContextID is specific, when ALL is used in the
TerminationID of a command, the effect is identical to repeating the
command with each of the matching TerminationIDs. The use of ALL does
not address the ROOT termination. Since each of these commands may
generate a response, the size of the entire response may be large. Thus
if the wildcard matches more than one TerminationID in the context, all
possible matches are attempted, with results reported for each one.  If
none of Terminations referenced by the wildcarded TerminationID are in
the specific context then error code 431 is returned. No errors are
returned for individual terminations specified by the wildcarded
TerminationID that are not in the specified context.
For example: Assume that the gateway has 4 terminations: t1/1, t1/2,
t2/1 and t2/2. Assume that Context 1 has t1/1 and t2/1 in it and that
Context 2 has t1/2 and t2/2 in it.
The command:
Context=1{Command=t1/*{Descriptor/s}}
Returns:
Context=1{Command=t1/1{Descriptor/s}}

In the case when the ContextID is wildcarded(i.e. ContextID = ALL) and
the TerminationID is fully specified, the effect is identical to a
command specifying the non-NULL context that contains the specified
termination.  Thus a search must be made to find the context and only
one instance of the command is executed. No errors are reported for
Contexts that do not contain the specified termination.  If the
termination is not contained in any (non-NULL) context then error 431 is
returned.  Use of this form of action rather than one specifying the
ContextId is discouraged but may be useful, for example in correcting
conflicting state between MG and MGC.

In the case when the ContextID is wildcarded (i.e. Context ID = ALL) and
the TerminationID is wildcarded, the effect is identical to repeating
the command with each of the TerminationIDs matching the wildcard for
each non-NULL context that contains one or more of those matching
TerminationIDs. Thus if the wildcard matches more than one TerminationID
in the specific instance of the wildcarded ContextID, all possible
matches are attempted, with results reported for each one. No errors are
reported for Contexts that do not contain a termination matching the
wildcarded TerminationID. No errors are returned for individual
terminations specified in the wildcarded TerminationID that are not in a
specific instance of the wildcarded ContextID. If there are no matches
to the wildcarded ContextID and TerminationID then error 431 is returned.
For example: Taking the above gateway configuration.
The command:
  Context=ALL{Command=t1/*{Descriptor/s}}
Returns:
  Context=1{Command=t1/1{Descriptor/s}}
  Context=2 {Command=t1/2{Descriptor/s}}
In the case that that multiple commands are contained in a wildcarded
TerminationID and/or wildcarded ContextID request then if the first
command does not match the first ContextID and TerminationID instance
then the subsequent command in the request will not be executed for that
instance.

If individual responses are not required, a wildcard response may be
requested. In such a case, a single response is generated, which
contains the UNION of all of the individual responses which otherwise
would have been generated, with duplicate values suppressed. For
instance, given a Termination Ta with properties p1=a, p2=b and
Termination Tb with properties p2=c, p3=d, a UNION response would
consist of a wildcarded TerminationId and the sequence of properties
p1=a, p2=b,c and p3=d. Wildcard response may be particularly useful in
the Audit commands. If a wildcard UNION response is used in conjunction
with a wildcarded Context then a single response is sent with the UNION
of all the individual termination/s referenced by the TerminationID. The
response would contain Context=all, a wildcarded TerminationId and the
sequence of properties.

If an error occurs during the execution of a wildcarded request that
specifies a wildcarded response special handling is required to provide
useful information about the error(s) while still maintaining a modest
sized response.  When wildcarded response is requested all instances (as
specified above) of the command shall be executed even if one or more
result in errors, but later commands in the transaction will not be
executed (unless optional was specified).  Multiple command responses
shall be returned for the command that encountered the error.  The first
command response shall be the normal wildcard response containing the
UNION of responses for those commands that succeeded.  If none of them
succeeded the UNION shall be empty.  Additional command responses for
each transactionID that failed shall be returned with the appropriate
Error Descriptor.

An example
     The command:
     Context=*{Command=t1/*{Descriptor/s}}

     Response to an error:
     Context=*{Command=t1/*{Union response descriptors},
              Command=t1/3{Error=errorcode}}

The encoding of the wildcarding mechanism is detailed in Annexes A and B.

-- 

------------------------------------------------------------
Terry L Anderson          mailto:[email-masked]
Tel:+1 908 766 4463
http://www.gti.net/tla

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

---

From: Raphael Tryster <[email-masked]>
Date: Sun, 20 Oct 2002 10:02:59 +0200

I think the description of wildcard response syntax is not detailed enough
to be useful, as it leaves open the question of whether unions are expressed
by repeating descriptors or making lists of values within descriptors.  In
my posting on the 29th of September, I claimed that anyone trying to
implement wildcard response would discover that a single answer to this
question will not work well, and I proposed a method of constructing the
wildcard response specific to each descriptor.  The replies indicated that
there is indeed a problem, and that the feature should either be defined
better or dropped.

Raphael Tryster

	-----Original Message-----
	From:	Terry L Anderson [SMTP:[email-masked]]
	Sent:	Friday, 18 October, 2002 6:44 PM
	To:	Megaco Mailing List
	Subject:	[Megaco] Wildcarding principles

	have appeared recently on the list.  Note that it modifies 6.2.2 as 
	shown and adds 6.6.  This is a D-283 submitted to the meeting as
modifed 
	during an editing session.

	6.2.2    TerminationIDs
	Terminations are referenced by a TerminationID, which is an
arbitrary 
	schema chosen by the MG.
	TerminationIDs of physical Terminations are provisioned in the Media

	Gateway. The TerminationIDs may be chosen to have structure. For 
	instance, a TerminationID may consist of trunk group and a trunk
within 
	the group.
	A wildcarding mechanism using two types of wildcards can be used
with 
	TerminationIDs. The two wildcards are ALL and CHOOSE. The former is
used 
	to address multiple Terminations at once, while the latter is used
to 
	indicate to a media gateway that it must select a Termination
satisfying 
	the partially specified TerminationID. This allows, for instance,
that a 
	MGC instructs a MG to choose a circuit within a trunk group.

	processing these commands two forms of wildcarding must be
considered:

	command with each of the matching TerminationIDs. The use of ALL
does 
	not address the ROOT termination. Since each of these commands may 
	generate a response, the size of the entire response may be large.
Thus 
	if the wildcard matches more than one TerminationID in the context,
all 
	possible matches are attempted, with results reported for each one.
If 
	none of Terminations referenced by the wildcarded TerminationID are
in 
	the specific context then error code 431 is returned. No errors are 
	returned for individual terminations specified by the wildcarded 
	TerminationID that are not in the specified context.
	For example: Assume that the gateway has 4 terminations: t1/1, t1/2,

	t2/1 and t2/2. Assume that Context 1 has t1/1 and t2/1 in it and
that 
	Context 2 has t1/2 and t2/2 in it.
	The command:
	Context=1{Command=t1/*{Descriptor/s}}
	Returns:
	Context=1{Command=t1/1{Descriptor/s}}

	In the case when the ContextID is wildcarded(i.e. ContextID = ALL)
and 
	the TerminationID is fully specified, the effect is identical to a 
	command specifying the non-NULL context that contains the specified 
	termination.  Thus a search must be made to find the context and
only 
	one instance of the command is executed. No errors are reported for 
	Contexts that do not contain the specified termination.  If the 
	termination is not contained in any (non-NULL) context then error
431 is 
	returned.  Use of this form of action rather than one specifying the

	ContextId is discouraged but may be useful, for example in
correcting 
	conflicting state between MG and MGC.

	In the case when the ContextID is wildcarded (i.e. Context ID = ALL)
and 
	the TerminationID is wildcarded, the effect is identical to
repeating 
	the command with each of the TerminationIDs matching the wildcard
for 
	each non-NULL context that contains one or more of those matching 
	TerminationIDs. Thus if the wildcard matches more than one
TerminationID 
	in the specific instance of the wildcarded ContextID, all possible 
	matches are attempted, with results reported for each one. No errors
are 
	reported for Contexts that do not contain a termination matching the

	wildcarded TerminationID. No errors are returned for individual 
	terminations specified in the wildcarded TerminationID that are not
in a 
	specific instance of the wildcarded ContextID. If there are no
matches 
	to the wildcarded ContextID and TerminationID then error 431 is
returned.
	For example: Taking the above gateway configuration.
	The command:
	 Context=ALL{Command=t1/*{Descriptor/s}}
	Returns:
	 Context=1{Command=t1/1{Descriptor/s}}
	 Context=2 {Command=t1/2{Descriptor/s}}
	In the case that that multiple commands are contained in a
wildcarded 
	TerminationID and/or wildcarded ContextID request then if the first 
	command does not match the first ContextID and TerminationID
instance 
	then the subsequent command in the request will not be executed for
that 
	instance. 

	contains the UNION of all of the individual responses which
otherwise 

	p1=a, p2=b,c and p3=d. Wildcard response may be particularly useful
in 
	the Audit commands. If a wildcard UNION response is used in
conjunction 
	with a wildcarded Context then a single response is sent with the
UNION 
	of all the individual termination/s referenced by the TerminationID.
The 
	response would contain Context=all, a wildcarded TerminationId and
the 
	sequence of properties.

	specifies a wildcarded response special handling is required to
provide 
	useful information about the error(s) while still maintaining a
modest 
	sized response.  When wildcarded response is requested all instances
(as 
	specified above) of the command shall be executed even if one or
more 
	result in errors, but later commands in the transaction will not be 
	executed (unless optional was specified).  Multiple command
responses 
	shall be returned for the command that encountered the error.  The
first 
	command response shall be the normal wildcard response containing
the 
	UNION of responses for those commands that succeeded.  If none of
them 
	succeeded the UNION shall be empty.  Additional command responses
for 
	each transactionID that failed shall be returned with the
appropriate 
	Error Descriptor.

	An example
	    The command:

	    Response to an error:

	The encoding of the wildcarding mechanism is detailed in Annexes A
and B.

	--

---

From: Raphael Tryster <[email-masked]>
Date: Sun, 20 Oct 2002 10:02:59 +0200

Raphael Tryster

	-----Original Message-----
	From:	Terry L Anderson [SMTP:[email-masked]]
	Sent:	Friday, 18 October, 2002 6:44 PM
	To:	Megaco Mailing List
	Subject:	[Megaco] Wildcarding principles

	6.2.2    TerminationIDs

	An example
	    The command:

	    Response to an error:

	--

---

From: [email-masked]
Date: Tue, 22 Oct 2002 11:39:01 +0530

Hi Terry

One issue which remained un-answered though!

Wild-carded terminationID in MOVE command.

TerminationID should resolve to all the terminations matching the wildcard
except the following:
1. terminations in null context
2. terminations in the destination context (specified contextID in the action)
which are discarded.

Considering your example:-
Context=1{MOVE=t1/*{Descriptor/s}}
returns
Context=1{MOVE=t1/2{Descriptor/s}}
and no error for termination t1/1 which is already in Context 1.

The command is attempted upon all the resolved terminations (except the
discarded ones).
No error is sent for the discarded terminations.
In case no termination was resolved in the valid set error code 431 is retuned.
If the number of terminations being MOVEd to the destination ContextID exceeds
the maximum value allowed per context, error code 434 is sent for all the
resolved
terminations for which command was not attempted.

regards,
Kapil Nayar
Hughes Software Systems Ltd.
www.hssworld.com

Terry L Anderson <[email-masked]> on 10/18/2002 11:13:37 PM

To:   Megaco Mailing List <[email-masked]>
cc:    (bcc: Kapil Nayar/HSS)

6.2.2    TerminationIDs

An example
    The command:

    Response to an error:

--

---

From: [email-masked]
Date: Wed, 30 Oct 2002 10:32:59 +0530

Hi Terry/ Kevin

Thanks for indicating about the discussions in Geneva.
That clears the doubts (a bit:) about not including the wildcarded
terminationID for MOVE command.

Just a clarification....on Terry's mail
"......But the MOVE issue is definitely still open.  Of course one
option is to not make any special rules for MOVE and simply admit that
wildcard *context*(**termination**) for a move makes little sense......"

Trust this was a typo error.
I suppose wildcard context ($ is allowed and * is invalid) is very clear
for MOVE command and doesnot need any further clarification.
However, the wildcard termination needs more clarification.
Although, as you pointed out there definitely seems to be an opinion that
MOVE with wildcard termination (moving more than 1 termination to a context
simultaneously) is more of an academic requirement than a practical
application scenario.

regards,
kapil nayar

Terry L Anderson <[email-masked]> on 10/29/2002 09:10:29 PM

To:   Kapil Nayar/HSS@HSS
cc:   Terry L Anderson <[email-masked]>, Megaco Mailing List
      <[email-masked]>

Subject:  Re: [Megaco] Wildcarding principles

I agree, but the group in Geneva felt that we could not settle the issue
quickly enough for inclusion in the change and that it was sufficiently
separable from the issues we were addressing, to proceed with the change
as is.  But the MOVE issue is definitely still open.  Of course one
option is to not make any special rules for MOVE and simply admit that
wildcard context for a move makes little sense.  But we should certainly
discuss the issue and make a decision.  If we decide on a clarification
that can become an additional IG issue.

BTW I (as rapporteur) have appointed Kevin Boyle (Nortel) as the new IG
editor.

--

---

From: [email-masked]
Date: Wed, 30 Oct 2002 10:32:59 +0530

Hi Terry/ Kevin

regards,
kapil nayar

To:   Kapil Nayar/HSS@HSS

--