Subject: ADD with CHOOSE (was RE: [Megaco] Race condition between Modify a nd Subtract)

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 20 Nov 2001 12:57:55 -0500

I believe the question comes out of the discussion below is this: is it an
error for the MGC to request an Add=$ without specifying enough information
to allow the MG to determine the termination identifier it should return?

I have to confess that I can't dodge the issue by saying that naming
patterns are a proprietary blot on the protocol.  Persistent terminations
will have terminationIDs amongst other properties, and the MG has to know
whether it is being asked to select from persistent or ephemeral
terminations.

Having accepted this, I took a look at the text of section 7.2.1 as it
stands in H.248v2, and particularly the first paragraph following the API.
I found a few other problems with the text -- it really doesn't address the
possibility of a partially specified termination identifier, and is rather
vague on a number of counts.  One item I commend to your attention: is it
reasonable to restrict the use of ALL wildcards in Add commands to physical
terminations?  I myself believe so, since otherwise the MG could end up
exhausting its resources in an useless frenzy of ephemeral creation.

Another point: the text currently says that all possible matches to an ALL
wildcarded identifier are attempted and the results for each reported.
Would it not be more consistent with the operation of the protocol to
terminate execution of the command if an error is encountered?

One final point: do people have views on whether the MGC can fully specify
the identifier for an ephemeral termination it wants the MG to create?

Anticipating your responses, I propose that the following text be added to
section 7.2.1, replacing all of the second paragraph beyond the sentence
"The Termination is either created, or taken from the null Context."
Brackets [] enclose comments, which are not intended to be included in the
new text.
 
<Begin replacement text>
  
The termination identifier included in the Add command may consist of an ALL
or CHOOSE wildcard alone, a partially specified termination identifier which
includes one or more ALL or CHOOSE wildcards, or a fully specified
termination identifier.  It is illegal to specify a termination identifier
containing both ALL and CHOOSE wildcards.  [.. because describing how to
interpret such an identifier would be too messy.]  The MG reports the fully
specified termination identifier for each termination successfully added to
the context as a result of the Add command. 

A CHOOSE wildcard alone indicates a request to create an ephemeral
termination and add it to the context.

Usage of ALL wildcards within an Add command would be unusual.  When they
are present, the termination identifier shall be interpreted to refer only
to physical terminations residing in the NULL context.  If no terminations
currently in the NULL context match the ALL-wildcarded termination
identifier in the Add command, the MG MAY return error 431 "No TerminationId
matched a wildcard" even if the identifier would match a termination already
in an active context.  [This saves the MG the pointless effort of checking
active contexts just to return a more accurate error code.]  If an
ALL-wildcarded termination identifier matches more than one TerminationID in
the NULL context, the MG shall attempt to add each matching termination to
the context.  The order of attempts when multiple TerminationIDs match is
not specified.  As usual, a failure to add a particular termination
terminates execution of the command; the MG reports the identities of the
terminations successfully added and an appropriate error descriptor for the
failure.

A termination identifier which is CHOOSE-wildcarded or fully specified may
designate either a physical or an ephemeral termination.  In making the
decision as to which to add, the MG shall use the following criteria in
decreasing order of priority.

 1) If the termination identifier is fully specified and it matches an
existing termination, the MG shall either add that termination or return
error 433 "TerminationId is already in a context" as appropriate.

 2) If the MG implements fixed naming patterns for particular termination
types then it shall process the given identifier accordingly.  Possible
outcomes include successful addition of a termination or error 430 "Unknown
TerminationId" if the given identifier does not match any implemented naming
pattern.  Other errors are possible, particularly if the given identifier
matches the naming pattern for physical terminations.

 3) If the termination identifier is fully specified and the type of the
termination has not been resolved by the first two rules, the MG shall
attempt to create and add an ephemeral termination to the context using the
given identifier.

 4) If the termination identifier is partially specified with CHOOSE
wildcards and matches one or more terminations currently in the NULL
context, the MG shall choose one of these terminations to add to the context
and report the result.

 5) Finally, if the termination identifier is partially specified with
CHOOSE wildcards and has not been resolved by the previous rules, the MG
shall attempt to create and add an ephemeral termination with a unique
termination identifier matching the pattern specified by the identifier in
the Add command.

<End of replacement text>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 19, 2001 11:39 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: 'Atanu Mondal'; [email-masked]
Subject: RE: [Megaco] Race condition between Modify and Subtract

Hi Tom

Please see my comments below:

"Tom-PT Taylor" <[email-masked]> on 11/19/2001 07:29:02 PM

To:   "'Atanu Mondal'" <[email-masked]>, [email-masked]
cc:    (bcc: Kapil Nayar/HSS)

Subject:  RE: [Megaco] Race condition between Modify and Subtract

Let me sum up what has been mostly covered by others: the type of a
termination is determined by the properties assigned to it.  In the absence
of a fixed naming pattern, the MG has to analyze the properties given with
the ADD command to decide what kind of termination to use.
<KN> Even if we have a fixed naming pattern, we need to handle $, because it
doesnot refer to any specific pattern or in other words it refers to any
naming
pattern.

In particular, in text encoding, the transport profile given on the m= line
of
the SDP
should be helpful when Local and Remote are present.
<KN> What if the MGC initially just does an ADD (term-$) without any
'distinguishing' descriptors or properties. Should MG generate an error for
this
case since the termination ID cannot be determined.

I have maintained in the past that if the type of the termination is
ambiguous, it can still be implemented as a software placeholder, pending
the receipt of further information.
<KN> Since MG necessarily needs to respond back with a fully-specified
termination ID (which should comply with a naming pattern either for
ephemeral
or physical), it may not be possible to pend the termination type decision
till
further information.

I suspect this is getting very close to
an implementation issue rather than a protocol issue, but it is feasible.
<KN> It would be helpful Tom if you can clarify.....from the protocol
perspective.

Thanks & Regards,
-Kapil Nayar

-----Original Message-----
From: Atanu Mondal [mailto:[email-masked]]
Sent: Monday, November 19, 2001 12:26 AM
To: [email-masked]
Subject: Re: [Megaco] Race condition between Modify and Subtract

Hi List,
I need some clarification regarding the addition of a termination in the
context.
How does a gateway understand that it need to create a ephemeral
termination and not physical termination.
Should there be any condition when the agent can send a "Add =$ "to
choose any physical termination
of the gateway, or the "$" is only meant for ephemeral termination only.

Thanking in advance

Regards
Atanu Mondal
Net Brahma Technologies Ltd

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

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